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

Why are organizations not seeing the benefits of doing Agile?

Due to a difference in goals and approaches, friction occurs between Agile teams and the rest of the organization - who has yet to see the benefits...

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.

Agility requires cultural change

Article published in German magazine it-daily.net

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

An experiment as a ScrumMaster and Agile coach working with a Sales team, where Agile practices are supporting new acquisition and retention targets

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.

Good VIBE at Scrumtisch Berlin

Scrumtisch March 2018 at SAP Berlin

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.

Step up your Kanban game

In the upcoming weeks, Accredited Kanban Trainers from agile42 will facilitate certified Kanban training in locations all around the world

Image of mikefreislich

Mike Freislich

Image of rhilll

Russell Hill

Image of mgaewsj

Gaetano Mazzanti

My background includes a long experience as a manager in the Software and Machinery Industry. I worked in USA and India leading distributed teams in advanced software projects (CAD/CAM, PLM, Industrial Automation, Plant Control and Supervision). As a coach I am now trying to help organizations to change embracing Agile and Lean values and principles. I am a WIP limit addict :) and a KCP