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

Complexity, Chaos, and COVID-19

Applying Cynefin & Complexity Thinking to navigate the COVID-19 crisis: a panel webinar on April 2

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.

Active Listening

Notes and video from the webinar run on March 20, 2020

Image of pascal

Pascal Papathemelis

Pascal has worked as an agile project manager/scrum master/facilitator of various developments in size and type for almost two decades. His focus is on people and practical approaches in order to deliver value. Currently Pascal is working at agile42 as an agile coach on a journey to help organisations and individuals grow, improve and become more efficient in a sustainable way.

A message from agile42 at time of COVID-19 epidemic

Our commitment to reducing to the minimum the risk of spreading of the Coronavirus disease (COVID-19)

Image of marion

Marion Eickmann

I am one of the founders and the executive director at agile42. I have supported strategic product development and leadership development for longer than 15 years. Since 2007 I have been realizing local and global agile projects with agile42's international team successfully. You like to talk about: ORGANIC agility, complexity, resilience, organizational culture & Agile? Just send an email :-)

Leadership Behaviours

Notes and video from the webinar run on March 13, 2020

Image of simsab

Simon Sablowski

Simon has spent several years working as a software developer, ScrumMaster and CTO. He is dedicated to shortening feedback loops to accelerate learning and strengthening team collaboration to maximise synergies. At agile42, Simon enjoys coaching and training teams and organisations that desire to attain higher productivity, continuous innovation and extraordinary performance.

Growing great upcoming ScrumMasters

We helped organize Scrum training for a new generation of students at the IT University in Copenhagen, Denmark

Image of giuseppe.desimone

Giuseppe De Simone

Giuseppe De Simone is a Certified Scrum Trainer (CST), Certified Enterprise Coach (CEC) and Certified Team Coach (CTC), passionate about helping individuals, teams and organizations become more productive by embracing Agile values, principles and practices. He is one of very few to be accredited from the Scrum Alliance as an educator of the Certified Agile Leadership and Path to CSP programs.