Scrum framework proposes Sprint Planning to plan the work for a given Sprint. The objective of Sprint planning is to discuss and plan the work with Product Owner and commit to the Sprint Backlog for a Sprint. Sprint planning meeting has two parts. Part 1 is to discuss with Product Owner to discuss WHAT stories can be completed in a Sprint (based on Sprint length) and Part 2 is to discuss within team HOW those stories would be implemented.
Too much time in Planning Meeting
Teams new to Scrum process spends lots of time in both Sprint planning meetings and still fails to meet their Sprint commitments. Bit more mature teams’ starts backlog grooming sessions, Sprint planning sessions gets shorter but still miss to complete the commitments in a given Sprint consistently. This leads to frustration within Sprint teams and Product Owner as well.
So what’s the solution?
Grooming++ sessions
Grooming sessions are a perfect example of Team working with Product Owners to define and refine the User stories. Product Owner presents the business requirements and works with team to slice the stories into small stories. Because whole team is working together to define (and refine) the user stories, the team has a consistent understanding of stories discussed in the grooming session. So what’s the issue? When we know what needs to be done so clearly, why team is still missing the commitments (despite knowing very well their expected velocity)?
The problem is that grooming sessions are only focused on WHAT but no time is given to understand HOW the stories will be implemented. As team starts to discuss HOW to implement stories in Sprint planning part 2 meeting, but estimates has already been given either in Grooming sessions (most of the time) or Part 1 of Sprint Planning meeting. When team starts working on the implementation of the stories lots of unknown appears i.e. refactoring, lack of understanding of code, difficulty to work with legacy code etc. So most of these unknown work leads to more necessary work but missed commitments.
Try this. After a grooming session (I call it grooming++), quickly discuss how the story or stories going to be implemented at high level. So have a quick look on the code and understand if there are any unknowns that need to be factored in your estimates i.e. Refactoring. A quick engineering drawing on the board using either of Class Diagram, Sequence Diagram, Flow diagram or any other diagram that you are comfortable with and after the session. Once you have understood the high level implementation details and any unknowns that needs to be factored in, you would have better chance to give accurate (ok, close to accurate) estimates. These sessions are more useful when you have a legacy code or even a Greenfield project where a team joined late and don’t have enough understanding of existing implementation (kind of legacy code for them). This exercise is very useful even if your stories are small because it gives you
