July 6, 2009

Sprint Planning, Just Enough & Just in Time

How to get a reasonable Sprint commitment without having to spend too much time in breaking down tasks at the Sprint Planning meeting, while being ...

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.

Image of andreat

Andrea Tomasini

I am an Agile Coach and Trainer and I am helping customers all around the world to become more Agile. I am more and more keen on adopting adaptive emergent approaches to improve people's quality of life. Through an holistic and pragmatic approach - I consider Lean and Agile very powerful frameworks - it is possible to improve results, performance and also personal satisfaction.
blog comments powered by Disqus
Image of andreat

Andrea Tomasini

I am an Agile Coach and Trainer and I am helping customers all around the world to become more Agile. I am more and more keen on adopting adaptive emergent approaches to improve people's quality of life. Through an holistic and pragmatic approach - I consider Lean and Agile very powerful frameworks - it is possible to improve results, performance and also personal satisfaction.

Latest Posts

Making Diamonds from your Retrospectives - The Diamond of Participatory Decision Making

As a retrospective facilitator, there are many insights and techniques that you can draw from the Diamond of Participatory Decision Making. 

Image of lklose

Lukas Klose

Article in Creditreform Magazine: Agility and organizational transformation

agile42’s Marion Eickmann, scientists, and business leaders weigh in on agility in an article published in the June 2018 issue


Image of marion

Marion Eickmann

I am one of the founders of agile42. Even though I am not an engineer I consider myself almost a "Techi" as I have been working in the field of software development for 10 years now.

Agile in Everywhere: Memories of a beginner-level Scrum servant

This is a story of a NGO adopting Agile principles and implementing Scrum in a non-IT context in Turkey and Scrum journey, from their perspectives

Image of aslis

Aslı Silahdaroğlu Bekmen

We are an independent humanitarian organization founded with the principle aim of helping disaster-affected communities meet their basic needs and rights. We are conducting our activities since 2005 with principles of humanity, impartiality, neutrality, independence and accountability.

Discussing large organizations in an Agile HR world

Peter Hundermark presenting a case study about a major agile transition at HR Goes Agile conference in South Africa

Image of peterhundermark

Peter Hundermark

Peter has worked with iterative and incremental software development processes since 1999, focusing on Scrum and Agile practices since 2006. In 2007 he started Scrum Sense in South Africa. He has introduced Scrum into scores of development teams locally and in Brazil. He leads certified Scrum training classes in South Africa and elsewhere. He is a Certified Scrum Coach and Certified Scrum Trainer.

ORGANIC Agility in Discover Germany magazine

An introduction to the concept of ORGANIC Agility presented in issue 62 of May 2018

Image of marion

Marion Eickmann

I am one of the founders of agile42. Even though I am not an engineer I consider myself almost a "Techi" as I have been working in the field of software development for 10 years now.