Iteration versus Iteration-less Scheduling

August 22, 2011 — Posted by Ken Pugh

In both Kanban and Scrum, there is an emphasis on developing software in small increments of requirements (stories). However the different approaches to scheduling between iteration-based Scrum and iteration-less Kanban can cause different behaviors to emerge from teams. These behaviors do not exist on all teams, but have been observed on many. One cause is that with iteration-less development, metrics and estimates can impose less overhead for the same net result.

Effort estimation measures

Teams need to provide some indication of how long it will take turn a requirement story into an implementation that is ready to release. This is commonly done using "story points" or t-shirt sizes. Both of these approaches indicate the relative effort between stories. The story point approach uses a numeric estimate where a story of three story points is estimated to take about three times the effort of a story of one point. The t-shirt size approach indicates size as small, medium, large, or extra large. The conversion from story points or t-shirt sizes to time is determined by experience for each team.

This initial estimate helps in planning. With an iteration approach, the team makes a commitment to complete a certain number of stories during each iteration. The estimate helps them to determine how many stories they can complete ("we can do this many story points in an iteration"). This commitment often forces a team to deal with the uncertainty of the estimates. Some teams spend not inconsiderable effort to estimate more precisely the effort for each story.

With an iteration-less approach, there is less need to have precise estimates since no commitment is being made regarding the number of stories that can be completed in a time period. Instead, an estimated cycle time is created. The story estimates (often in t-shirt sizes) helps distinguish stories of widely varying sizes to aid in predicting their cycle time. Differently sized stories effect cycle time. A large story takes much more cycle time than a small story. Small stories that are started after a large story will have a longer cycle time than small stories started before a large story. Some Kanban teams have separate workflows for different sized stories to make a better prediction of cycle time.

Metrics and Behavior

With an iteration approach, a key metric is "velocity": the total number of story-points for stories completed within an iteration. In the initial iterations, a team's velocity is usually lower than in later iterations since the team is in the formation stage: discovering about each other, the project domain, and any new technology required for the project. There are two ways to increase velocity. Velocity can increase naturally as the team matures and gets more adept. The other way is to break a story down into smaller stories that can be completed during an iteration. For example, a requirement story is often broken down into an analysis story, a development story, a testing story, and so on. This way, the analysis story can be done in the iteration prior to the development story and testing can happen late in the iteration. The more stories there are, the more are completed this makes velocity appear to be higher. I say "appear" because the requirement story still requires several iterations to complete.

With an iteration-less approach, the metric is "cycle time": the elapsed time from when a story is placed on the input queue to the time it is put on the ready to release queue. Decreasing cycle time is a measure of how the team is becoming more effective in implementing stories. Often this is accomplished by eliminating delays or waste in the process. With cycle time, there is less tendency to break stories into sub-stories (such as an analysis story) because finishing the sub-story does not complete the requirement story on which the cycle time is based.

As a side-note, for stories such a "fix-a-bug", whose effort is difficult to estimate with any precision, reasonable iteration-based scheduling is impractical. Teams concerned mostly with difficult to estimate stories often used iteration-less scheduling. However the cycle time often cannot be predicted, since the stories themselves are less-estimable

Example

Suppose there is a story that would take the entire team two weeks to complete.

In an iteration-based approach, using a normal two week iteration, the team would probably not accept the story as is because there is the chance that it would not be completed within the two week timeframe. Failure to complete the story would give a velocity of zero for that iteration, which looks bad. Rather, the team would spend time breaking down the story into multiple sub-stories so that in the event of slower development, at least a large percentage of the stories would be completed. .

In an iteration-less approach, the story could be accepted as-is. The story might be broken down into tasks, so that internal progress could be tracked more granularly. But the cycle-time for the overall story would be the same (two weeks) regardless of whether it was broken down or not. If it took slightly longer, the cycle time might be two weeks and a day.

In both cases, the effort it takes to complete the requirement story itself will be the same. However, in iteration-based approach, there is the additional overhead of more precise estimation and breaking stories down into smaller stories. In the iteration-less approach, the emphasis is on "just doing it."

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Ken Pugh

Ken Pugh was a fellow consultant with Net Objectives (www.netobjectives.com). He helps companies transform into lean-agility through training and coaching. His particular interests are in communication (particularly effectively communicating requirements), delivering business value, and using lean principles to deliver high quality quickly.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban