Sprint Planning, Just Enough & Just in Time

Never had the problem that the Sprint Planning Meeting often is at risk of going out of the time-box, and eventually the Development Teams didn't manage to fill up the Sprint Backlog with all the needed tasks?

I want to share with you a way - for sure no rocket science, but "Common Sense" as Ken would say - in which you can have a team committed to the deliverables, without having to struggle with the tasks breakdown, and at the same time having a "good enough" understanding about the commitment given to move forward... interesting? Than read forward :-)

The idea is pretty simple, and it is based on two important points:

• The Cone of Uncertainty[^1]: tells us that when you estimate Stories (which can be considered an equivalent of User Level specification) you may very well still be in a range of error of a factor 1.5 (from 66% -> 150% of what you estimated), this factor goes to 1.25 when you are at a task level.

• Planning Poker & Relative Estimation[^2]: measures the relative size (or proportion) of stories compared to each other, and can be used to derive the absolute size (normally expressed in Ideal Hours/Days).

Assuming that what the Development Teams commit to, is to deliver User Stories as potentially shippable product increments, and that they estimate those using the Planning Poker technique, you can proceed as follows:

1) Start the Sprint Planning in a normal way, take as much time is needed for the Teams to understand the User Stories and estimate them using Planning Poker. Make sure The Scrum Master has collected the "capacity" information for the current sprint from the Team Members.

2) When the Development Team sense that they already estimated enough stories to chose from for the current Sprint, they will have to commit on those they feel comfortable in completing (here it is still stomach+gut feelings and Development Team Velocity).

3) The Development Team start to break down the most valuable User Story into tasks, the rule here is to really sit down and discuss the details of the implementation to make sure that the Development Team has a complete and good understanding of what that Story involves. When the Team agrees that for what they can see all the needed tasks have been identified, they start estimating them (not before, helps in giving the team the overall plan and avoid discussion as: "I thought it was included in the task before...").

4) When the first and most important Story has been broken down into tasks, and estimated in details, the Team will have to review the relative estimation made and check if it really complies to their expectations. If not the team can change the Story Points Assigned to that story.

5) The Team can calculate the Remaining Time vs. Story Points ratio, and use it to project it on the remaining amount of story points committed for the sprint, coming out with an initial forecast of the total amount of time that would be needed to complete the whole committed stories. E.g.: Assume we have the following situation, the Team committed to 4 stories and estimated them the following story points: Story A: 13p Story B: 8p Story C: 3p Story D: 5p

After having broken down the first story, the Team comes to 130h (Ideal hours of work) to make that story potentially shippable. That would mean that the ratio Remaining Time vs. Story Point will be:

130h / 13p = 10h/p

So the whole Sprint effort, estimated to:

13 + 8 + 3 + 5 = 29p * 10h/p = 290h

Considering a Team of 5 people with an ideal daily capacity of 6h per day, that would tell the Team pretty fast that they are close to the 300h of ideal capacity in an hipotetical 2 weeks Sprint (5 team members * 10 days * 6h).

The idea is to estimate "Just Enough" Stories to have the Team able to make a detailed plan of what will happen in the next 3-4 days maximum (which is already a good forward looking) and than Inspect & Adapt daily and extend the plan based on what the Team finds while working.

6) The Development Team keeps on estimating what is needed when is needed "Just in Time" to have a detailed plan for the next coming 3-4 days of a Sprint, always updating the Real Time/Story Point ratio, and keeping under control the Sprint Capacity.

In this way the estimations will be based more on "Facts" and short loop verification rather than assumptions, often I have been seeing Teams feeling compelled to put some tasks and assigned some hours to those tasks, that would have eventually come into light in about two or tree weeks, if not four. This may happen for many reasons, can be that the Team is just tired to estimate and not more focused on making a plan, or just that what they try to achieve is too far away to be grasped and understood, therefore effectively planned. Often it is also the case that a lot of tasks ends up being dependent on the new implementation made during that same sprint, so estimating them before having implemented the new stuff, may result in being a Waste, cause the actual implementation may differ from the initial plans. I found this being a very useful practice in many Teams we coached, so I am sharing this with you :-)

Best
ANdreaT

[^1]: Based on an original study from NASA which came to the conclusion that in the beginning of the project life cycle (i.e. before gathering of requirements) estimations have in general an uncertainty of factor 4. This means that the actual duration can be 4 times or 1/4th of the first estimations. [^2]: Planning Poker is a consensus-based estimation technique for estimating, mostly used to estimate effort or relative size of tasks in software development. It is a variation of the Wide-band Delphi method. It is most commonly used in agile software development, in particular the Extreme Programming methodology.