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 :-)


[^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

How Do You Define Success?

Build the vision for success by asking questions, adopting the mindset for small rapid failures, and  improving continuously through validation.

Image of hwong

Hazel Wong

Marketing Assistant at agile42. Passionate about gaining insights from data in order to create content that resonates with the audience. Eager to help teams and companies open their mindset about the application of agile methods to address their challenges.

Three men in a boat

agile42 is looking to hire a salesperson for Sweden and Finland to make our network grow

Image of giuseppe.desimone

Giuseppe De Simone

Giuseppe is a Certified Enterprise Coach and a Certified Team Coach who is passionate about helping individuals, teams and organizations become resilient and agile. He is one of the only two CECs living and working in Sweden.
Image of lasseziegler

Lasse Ziegler

Lasse Ziegler is a agile and lean consultant, trainer and coach. He has over 10 years of experience in complex and difficult software development project and software product development.
Image of mvonweis

Martin von Weissenberg

Martin helps people understand agile and lean thinking and coaches teams and organizations in the use of agile methods and practices. He is a Scrum Alliance Certified Enterprise Coach (CEC) and is working on a PhD on how to manage and organize for agility.

Tickets on sale for Agile Days Istanbul

agile42 is a sponsor of Agile Days Istanbul, “The Most Agile Event”

Image of ebru4984

Ebru Yalçınkaya

I act as a change agent where the teams, domains need to enhance agility to reach their goals, to create a shared vision if needed. I coach every kind of team , every domain, like management teams or like customer care, technology and sales groups.

State of Scrum report for 2017-2018

The Scrum Alliance published the State of Scrum report for 2017-2018, a survey of more than 2000 Agile professionals

Image of abragad

Alessio Bragadini

Web community manager of agile42, trying to post relevant, informational, fun bits of content on the blog and social networks

Jan Barnes joining agile42

Jan Barnes joining agile42 as an Agile coach in the Canada team

Image of davesharrock

Dave Sharrock

Agile coach passionate about getting things done; helping teams exceed expectations, delivering organizational excellence, and all while having fun doing what they do.