Sunday, April 1, 2012

Possible new scrum extension

Scrum is evolving and changing. Product Backlog Items evolved from prioritized to ordered. Product Backlog grooming is becoming a Generally Accepted Scrum Practice (GASP). Charles Bradley has also blogged about some new direction scrum is taking. Burndown is no longer an artifact, but increment is. Ron Jeffries frequently writes (in scrum development yahoo groups) about small, similar sized user stories and working in smaller chunks instead of large user stories.

David Starr has already proposed an extension (Feature focused daily scrum ). Along these lines, I want to propose a new extension "JIT Planning"

Proposed Name
Just In Time (JIT) Planning

The PO already has an ordered list of backlog items.The team starts the spring with a planning meeting where they together to discuss the features that will be taken up during the current sprint.  The planning meeting consists of two parts, the "what" part where the PO and the development team understands the scope of the backlog items which need to be considered for the current sprint (mostly in the form of user stories), and the acceptance criteria for each of those backlog item. The Product Owner should be present during this part of the meeting. The second part consists of the "how" part where the team decides how to implement the the stories and the tasks associated with it. Usually, the sprint backlog is a set of tasks associated with those product backlog considered for that sprint. Though the product owner's presence is not usually required for the second part of the planning meeting, he should be able to help the development team if any clarification is required. For teams where the sprint duration is 30 days, the spring planning meeting can take a whole day (8 hours, split as 4 hours for the first part and 4 hours for the second part). For teams having a shorter sprint duration (say 2 weeks), the sprint planning meeting is proportionately short (4 hours for a 2 week sprint).

Proposed Change

The scrum team maintains the cadence by having their regular "what" part of the sprint planning meeting. These backlog items conveys the theme of the current sprint.

The "how" part  is broken down into a series of "JIT planning" meeting for each PBI.  The development team initially addressed only for the top-most backlog item. It then works on turning this PBI into a completed feature. Once it is complete, the team picks up the next backlog item, discusses different tasks associated with it and discusses how to turn that to a shippable increment. This is repeated for all the backlog items taken up for that sprint.

1. The team is co-located or has a very high bandwidth communication channel so that the team can swarm over/plan an impromptu "JIT planning" meeting once a feature is implemented and tested.

2. The backlog items are well groomed, estimated (story points) and/or diced to small stories which can be implemented in a day or two.


1. One Piece Flow helps the team deliver as fast as possible: The development team explicitly focus on one PBI at a time without switching context between backlog items. This should help team complete the feature faster. The impediments for completing that particular feature become much more evident (since the team cannot work on completing the feature) and those responsible for removing the impediments (the scrum master, product owner and management) are much more proactive in identifying and removing any impediments. Also, no one, including the team members can gloss over  the impediment by saying something along the lines of  "I have this impediment for this top priority feature, but that's OK because I am focusing on implementing some other product backlog item".  Also, the scrum master (and who ever is responsible for removing the impediment) becomes more effective as he is focused on removing all impediments related to a feature than just shot-gunning on impediments of multiple backlog items. With a good backlog with well defined acceptance criteria, backlog items should be implementable in 1 or 2 days. With stories that small, no explicit tracking is necessary ( Conversely, if the story is large, which may take 3-4 days, it might be a better idea to track the remaining efforts for the feature using a burn-down. Also see #6)

Johanna Rothman modified the daily stand-up question to "What feature did we complete yesterday ? What feature are we going to work on today?  What are the impediments to implement this feature?" JIT planning and one piece flow (execution) sets a boundary for the team (sprint backlog being implemented), and helps answer the modified daily stand-up questions.

2. Encourages team becomes more cross-functional: Since the focus is on completing the feature, it challenges the team members to get out of their comfort zone and learn new skills (if required, or hone their existing skills) to complete the feature at the earliest. A tester can no longer say "I am done writing the automated test case for this feature, but since the DB work is not done, I cannot fully test it" . Instead he focuses on contributing what ever he can to complete the database related task.

3. JIT planning eliminates waste:  The development team forecasts the product backlog items which it can deliver during a sprint. As the team gains more experience (with scrum, with the product, with technology and knowing each other), their estimates get better. But they are still estimates. By only targeting ( tasking out) one PBI at a time (and completing it), it avoids planning for features which may not be completed during the current sprint. Why plan for something which you might never need?  Remember- one of the agile principles is " Simplicity -- the art of maximizing the amount of work not done -- is essential"

4. Plan at the Last Responsible Moment (decide as late as possible): The team continuously learns about the product as well as about the technology used to build the product. Though the tasks associated with the sprint backlog can change, with JIT planning, we plan for the PBIs after gaining as much as much knowledge as possible. Since JIT planning focuses on the implementation for only one PBI, chances that the tasks associated with the PBI being missed out are much less. If the sprint duration is long (say 30 days), planning out the tasks just before the execution helps the team in easily remembering the design/execution strategy. On the corollary, it is very hard to remember a discussion about the tasks, designs and possible execution strategy (for a particular backlog item) which happened 20-25 days ago.

5. Development team member does not lose much if he he away during spring planning: Face it, in real life there are unforeseen emergencies, vacations and off-days. And if that happens to be on the day of sprint planning, he/she is missing out a lot. Though I would not like to call it an advantage, JIT planning minimizes the impact of a team member being away during the "how to" part of planning by distributing the "how to" for all the backlog items throughout the sprint. I assume that, in any team, the other team members will bring this person up to speed once he is back and the "burden" of getting that person up to speed is much less. Disclaimer: This point, in no way, encourages team members to stay away during planning, instead , I just want to convey the the impact of that event is reduced for the person and for the team.

6. Focuses on feature implementation explicitly rather than tracking efforts: Most of the commercial tool vendors have some form of sprint burn-down charts where the "ideal" trend is mapped along with the "actual" effort remaining. As bad as it might be, this brings up comparison between ideal burn-down, the actual and the variance. If JIT planning is used an ideal trend-line for the sprint backlog would not be possible as not all tasks and efforts have been identified for all the sprint backlog items.  If the stories cannot be split to smaller stories/features which can be implemented in a day or two, but takes three, four or five days to complete, it might be worth while to track the remaining efforts (for the tasks associated with that feature) using a burn-down chart (only for that feature). Considering this, the sprint can have as many "feature burn-downs charts" as the number of features taken up for implementation for the current sprint.

These are some of the ideas which, I hope, will help the team be more efficient. Please feel free to share your thoughts.


  1. Ram,

    1. I'm assuming all of the text above the "Proposed Name" will not be part of the extension.

    2. JIT planning is already an option in the base Scrum Framework, so I'm not sure that what you're proposing is different enough to warrant an extension. For instance, in the 2011 Scrum Guide:
    "However, enough work is planned during the Sprint Planning Meeting for the Development Team to forecast what it believes it can do in the upcoming Sprint. Work planned for the first days of the Sprint by the Development Team is decomposed to units of one day or less by the end of this meeting"

    "The Development Team often meets immediately after the Daily Scrum to re-plan the rest of the Sprint’s work."

    OTOH, maybe your specification of selecting JIT planning over full Sprint planning is enough of an extension -- could tell you better than I on that.

    3. I don't believe that your Advantage #1 is always true. I think it leads to delivering faster over time, but one piece flow does not always lead to faster or more efficient delivery in the short run.

    4. I would change Assumption #1 as follows:
    Change "the team" to "the entire Scrum team"

    5. For Advantage #6, rather than going into the long explanation about a task/hour burndown, I'd rather see you encourage a PBI/feature/story count burndown, since you're recommending PBI's that are so small.


    1. Thanks for taking the time to review Charles.
      1. Yes, that text is explanatory

      2. Yes, I am proposing that the a full "how to" part of the planning meeting is not necessary. Some of those stories might make it through the sprint, some might not. So why waste efforts. Instead, take a story, figure out "how to" for that story, complete it and then work on the next story

      3. Yes, you are right, but you get the idea. The goal is to minimize context switching. If there is certain delay in getting an impediment removed, you can proceed to the next one. Scrum is just common sense.

      4. I mean "the development team" + possibly the Scrum Master. Since the "how to" part does not heavily depend on the PO, he need not be present.

      5. I am thinking about removing the burndown section, guess it is too confusing.