Writing the Product Backlog Just Enough and Just In Time

12 February 2008

Mike Cohn
Mountain Goat Software

Some people want to take the stance that no work should be done in advance of the sprint. That is clearly untenable. To see why, let’s take that view to its extreme: If we did nothing in advance to understand what we're building, we’d show up at the planning meeting and say, “Hey, what should we build this sprint? We were working on an eCommerce site yesterday, but I think maybe we should switch to writing a word processor...” The team would literally have nothing written down—no product backlog / user stories / prioritized feature list at all.

This approach leads to what I call “billiard ball sprints.” Without any planning, the team starts a new sprint on the day after the prior one end, but spends the first two to five days “getting ready” to start the sprint. The start date of the second sprint is knocked forward by the end of the first—like one billiard ball knocking into another.

Having dispensed with the possibility that no work should be done in advance we are left to consider the question of how much work should be done in advance. Many say that as little as possible should be done: the team should do no more than write a few words of a user story on an index card to represent each product backlog item. While it’s true that this may be sufficient in many cases, it would clearly not be adequate in all situations.

My view is that each product backlog item (usually reflected as a user story by teams I train or coach) should be captured just in time and in just-enough detail for the team to go from product backlog item to working, tested feature within a sprint. To see why just-in-time and just-enough are appropriate targets, suppose we decide to write a checkbook program to compete with Intuit's Quicken product. We create an initial product backlog that includes these two user stories:

  • As a user I can see the current version, company website, and copyright in a "help about" dialog so that I know useful information about the product.
  • As a user I can enter a check in my register so that I can track who I pay.

That first story can go from that short description to implemented code quite easily within a sprint. The analyst will have time to figure out exactly what the text should say; the user experience designer (UED) will have time to mock up two or three screens, show them to some users, get feedback, and create the best possible “help about” screen. And the programmers will have time to code it and the testers to test it. In short, it meets the just-enough-detail criteria.

The second user story, “As a user I can enter a check in my register,” is too big to be done in a single sprint. It encompasses the entire main user interface (UI) metaphor—will our system look like a paper check register? How many rows in the register? How will users choose things like check numbers or electronic funds transfer (EFT) transactions, and so on. There is no way the UEDs can figure all that out in a two-week sprint. This user story is not explained in just-enough detail. This is where our second attribute comes in: detail should be added to this user story (product backlog item) just in time. If the team will not work on this user story for six months there is no need to expand on what is already written. On the other hand, if the team hopes to start it in a few sprints, it is likely time for the UEDs to figure out the answers to the high-level questionslisted above.

To do this, they’ll need to allow time to “figure out the answers” in the upcoming sprints. Let’s say that during the first sprint the team chooses to work on the “help about” story and likely a few others (not shown in our sample product backlog above). They also agree to spend some time figuring out what the main UI metaphor for the system will be.  During this time the UED may design a couple of screens and show them to a few dozen or hundred users, get feedback, and do it again. This may happen a few times. When they finish they may have turned that one user story (as a user I can enter a check in my register) into a dozen smaller stories, perhaps specifying what fields are needed and other details such as:

  • As a user, when I enter a new check it defaults to the last check number + 1
  • As a user, I can enter a memo for each check, etc.
  • As a user, I can double-click on a check in a list and see the current item look like a paper check.

In some cases splitting a large story into smaller ones is sufficient to show the new items at the right (just-enough) level of detail. When it’s not, we can augment the user story with additional information. I like to write user stories on index cards. That was sufficient for the "help about" story. It’s not for the initial large user story encompassing our system’s main UI metaphor. If splitting a story does not add just-enough detail, the UED and others involved may want to staple a UI design spec to the index card. (If you are using a software system for managing your product backlog, your virtual staple may be a hyperlink to a wiki page.)

The UI design spec that is stapled to the user story card will not yet be perfect; rather it will be close enough that remaining details can be figured out during the sprint. For example, the UED may not yet have decided if each check should take two rows or three on the screen and wants to do a bit of user testing early in the sprint while the team codes that story. He'll get them an answer early enough that they can do it either way during the sprint. 

The goal of the UED (and anyone else involved at the time) is to add detail to the story in a just-in-time manner. There is usually no value to splitting a large user story up now or stapling a document to it if we won’t work on that product backlog item for quite awhile. While working to add detail in a just-in-time manner, those doing so should strive to add just-enough detail that no individual item will take more than one sprint to complete. Just-in-time and just-enough become the targets for establishing a smooth flow from product backlog to sprint backlog.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 5 (1 ratings)

Comments

Haim Deutsch, CST,CSC,CSM,CSPO, 2/12/2008 5:22:55 AM
Yeah, gotcha!
You just removed my biggest problem.
I had always difficulties to explain my coached people when to capture product backlog items. It is in general pretty easy to explain just-enough (i usualy didn't give this name but well-defined-item), it is much difficult to explain when to begin define complex user-stories (i used to call them story-what? ). I will certainly use your example it is just-enough and just-in-time as both.
however to be entirely honest, i remain with the difficulty of correctly extimate how long time it will take to the product manager to reach just-enough storie, and this is inherently due to the un-defined nature of the item. Honestly this is where I fall (when I do fall at all :) ). This why I generally advise to prompt as soon as possible such items, and begin to define them ASAP too, this is risk management when the just-in-time value is not definable. So we pull down the risk for the teams to not have enough sprints to implement the meta-item.
Another reason to begin to define it ASAP, is for estimation and planning needs. If you have to commit to a release date, it become critical to be able to put a story-points stamp on the index card(s).
Let say that this is thinking material. I entirely agree with Mike's article, and will use it for training and implementation.
Thanks.
Mike Cohn, CST,CSP,CSM,CSPO, 2/12/2008 12:25:41 PM
Hi Haim-
I'm glad you found this article helpful. I have teams estimate with the sequence of values 1, 2, 3, 5, 8, 13, 20, 40 and 100 (story points or ideal days). I ask them to think of those numbers as buckets. A 13-liter bucket cannot hold a 14 or 15 liter backlog item so that item is put in the next larger bucket (20 in this case). This helps some with the risk of estimating the large items early. The goal with estimates like that should really be around deciding whether a feature is worth doing and whether we should do it in this release or the next. But you are right that when more precision is desired in the estimate, it can be helpful to split a product backlog item (user story) up sooner.
Haim Deutsch, CST,CSC,CSM,CSPO, 2/13/2008 9:56:04 AM
Swell Mike, I'm using too your Fibonacci story points-serie, and it is the best tool I found around in order to estimate tasks. But were I 1000% agree with you is concering the question "is a feature worth doing for the current sprint". I'm pushing the question to its extrem "is a feature worth doing for the current release!" And as you know, we have often the conviction that it shall not be done for the current release/sprint, but postponed to the next one. However it is not less often much difficult to explain the price of doing this feature over other. Using story points, you show not only the price, but certainly the cost too. And this is a winning argument!
Geir Amsjo, CST,CSP,CSM,CSPO, 2/26/2008 6:49:35 AM
Thanks Mike, this is an area in need of some better guidance!

I have experienced Sprint planning with almost no preparation or understanding of the Product Backlog; Very frustrating and the Sprint suffers from day one. And I have experienced the opposite; We are well prepared, have more than enough estimated Product Backlog Items, some ROI evaluations and even some technical considerations done. The Sprint is likely to run much more smoothly.

At a client we made a very simple rule, just to make sure that we found the time to work on the Product Backlog in advance of Sprint Planning: We simply reserved 2 hours a week (every wednesday at 12 o'clock) for "Backlog Work". Almost every time the Product Owner har a lot of new items to discuss and estimate. When we started to use Planning Poker theese meetings became even more valuable. After that the Sprints have had much better success rate, and the Product Owner have been able to prioritize better accoring to Cost / Benefit evaluations.
Mike Cohn, CST,CSP,CSM,CSPO, 2/26/2008 8:08:14 AM
Hi Geir--It sounds like you've discovered some great subtle ways to improve things for your team. That's fantastic.
Mike Lowery, CSP,CSM,CSPO, 2/27/2008 2:00:25 PM
Great article mike, this will be a great resource for me to point people at when I can't quite get the message across.
On the last project I ran we had all of the discovered product backlog items on the wall next to the dev team in the standup area. It really helped to keep what might be next in the minds of the team and whilst the stories may not have been fleshed out no one had a major surprise. The Other benefit we found was that during the development of an in-sprint story we would often spot backlog items that became redundant.
Mike Cohn, CST,CSP,CSM,CSPO, 2/27/2008 3:56:15 PM
Hi Mike--It is amazing how even a little bit of visibility (e.g., upcoming cards posted to a nearby wall) can really help the team.
Quentin Gilbert, CSM, 3/19/2008 8:51:39 AM
I think you've coined a new phrase, Backlog JITJE !!
Cindy Shelton, CSM, 3/31/2008 7:43:36 PM
Mike,
Might I drop a note here? I do this a bit differently and that has me a little concerned as I would not want to get too far from the tree....
When I build the backlog - I build the pile of stories to match one of two visions: basic stories for everything that is expected to be done, with point estimates, for later use for targeting end dates based on our actual velocity AND/OR with just enough detail that business value can be extracted in sub-stories should that be possible. The first vision is so that those who want to see it, can view the progress and the trend line for a targeted completion and start communicating that soon. The second vision is also for the PO to extract some possible opportunities of items that are a higher business value or from the IT side to identify some possible opportunities to address risky items earlier. This is fundamental to my thinking.
JIT detail may be alot of detail or very little - depending upon what level of detail the team needs to cry "uncle" using Paretos rule when they have enough information to estimate or anything in that story if broken out would be of equal business value. I really have to pull back teams from the detail as an everyday mantra for awhile and remind them of the 80/20 rule, but the overall effect has been more positive than squashing the detail when it rears its head. Your thoughts?
Mike Cohn, CST,CSP,CSM,CSPO, 4/1/2008 12:52:47 AM
Hi Cindy--
I don't exactly follow what you do. From the above it sounds to me that you are doing something similar to what I advise, which is (a) writing product backlog items at different levels of detail based on things such as priority, risk, etc. (b) progressively adding detail as needed, and (c) not adding detail too far in advance. If so, what you're doing sounds fine to me.
Matt Roadnight, CST,CSP,CSM,CSPO,REP, 4/8/2008 4:13:02 PM
Mike, youΓÇÖve highlighted an area that we have been working on for some time, initially like most people we struggled with the concept that very little work should be done up front, we found very quickly that this wasnΓÇÖt possible or responsible. Over the last four years we have looked at how we deliver our projects in an Agile way, balancing the Agile manifesto principles with the needs of generating just enough information to enable our development teams to deliver ΓÇ¥engaging web sitesΓÇ¥.

For those that interested in knowing more I will be presenting at the Scrum Gathering in Chicago how, as leading interactive web design company, Conchango approaches this problem and the artifacts and techniques we use to deliver our Agile projects.

So if you havenΓÇÖt already signed up and are interested register now, if you have registered it will be good to see you there
Anthony Boobier, CSP,CSM,CSPO, 5/12/2008 5:01:50 PM
Mike - great that you use the Fibbonaci sequence, but a question what do you do about the unknown stories - the "?" ? Do you break these down into smaller stories or even Spike them ? or even leave them at 100 and break down at a later date ? If you Spike do you size the Spike ?
Mike Cohn, CST,CSP,CSM,CSPO, 5/12/2008 8:42:55 PM
Hi Anthony-- Usually when a team puts a "?" as the estimate on a story it means they don't know enough about it at the time to estimate it. The solution is usually to get more information from the PO about what to build or to develop more technical knowledge about how to build it. The PO may need to go do market research; the team may need to look at some code or do some research. If the team does a spike (a learning activity) I don't put story points on that but do include it as planned work during the next sprint planning meeting.
Rachel Maple, CSM, 6/8/2008 6:07:33 AM
Mike - this great, a lot of our backlog item is very big, I have been gathering team and called a pre-sprint planning to breakdown the backlog item into smaller estimate size ( less or equal size 13 with your playing poker card). do you think the story point size 13 is a right size for team to work and complete within the cycle ( we have 2 weeks cycle)?
Mike Cohn, CST,CSP,CSM,CSPO, 6/8/2008 6:20:34 AM
Hi Rachel--I'm glad you liked the article. Yes, for most teams I work with a 13-point user story is achievable within a two-week sprint. That's on the upper end of what most teams can do in a sprint. I often ask product owners to spend some time a few days before the start of a sprint making sure that we have plenty of small- to medium-sized user stories at the top of the product backlog. They do this in the same type of pre-sprint planning meeting you describe. Often it's the PO and a subset of the development team, just enough to make sure the splits achieve the goals. (Without a developer or two handy, a PO could split one user story into five yet leave 99% of the work in one story.)
Jay Conne, CSP,CSM, 8/21/2008 10:15:40 PM
Hi Mike - This is a nice summary of what I have learned from your great books. Can you add to this discussion the elephant-in-the-room context, 'architecture'?
The Agile/XP community is split on how much to specify and when. I'm having this as a debate topic at MIT for the Agile Bazaar in November with Jim Coplien and Bob Martin. Your thoughts now?
Mike Cohn, CST,CSP,CSM,CSPO, 8/22/2008 3:38:44 AM
Hi Jay--You are absolutely right. I find that the exact same advice I give to User Experience Designers is what I say to architects: "Just in time, just enough." Some things need to be thought through more than others so do so when there will be value. As for the debate between Jim Coplien and Bob Martin, I'm going to come down in favor of Bob's stance. I've heard the arguments and I've seen enough instances where emergent designs or architectures have worked extremely well and likely better than an upfront big design would have.
Andrea Tomasini, CST,CSC,CSP,CSM,CSPO,REP, 4/1/2009 12:59:58 PM
Hi Mike, you got it again :-) If I may add something - to make it full JEJIT - we also use to break down the tasks during a Sprint on the way, depending on what is the status of the system at any given time. How we do it? We take the highest prioritized stories, we break "Just enough of them" into tasks during the Sprint Planning Meeting, just enough to have everyone in the team starting to work for 2-3-4 days (depending on the sprint length). To calculate the Burndown chart in hours we use the coefficient USP/RT (User Story Points/Remaining Time) calculated on the estimated stories, and we project it on the non broken down stories. In this way the Team is focusing on the most important story first, and breaks down into detail the upcoming as needed. Every time a Story gets real tasks, the estimation of the tasks prevail the relative/derived estimation. This as also the advantage that at the Retrospective the Team can measure their estimation and get a feeling on how good they have been.

The Team also dedicates about 10% of time to do the "lookahead" during one Sprint and see what is coming in the Product Backlog, in case they identify something really complex, that would require a significan amount of time to be "broken down" in committable details, the Team can ask the Product Owner at the next Sprint Planning meeting to have a "Spike" - named like that cause will make a Spike in the velocity chart - that is a timeboxed effort to investigate on a story, that may output a set of detailed user stories.

We also make extensive use of User Stories Workshops before starting a new Product Release, where the Product Owner invites the Team and in 4h timebox, they generates together Stories, to solve specific Needs that the Product Owner present to the Team in order of Value. The effect is double, the Product Owner gets a lot of ideas, and the Team gains visibility on the Release content, and implicitly acquire a better understanding of the stories, during the workshop.
Mike Cohn, CST,CSP,CSM,CSPO, 4/1/2009 8:09:02 PM
Hi Andrea--Thanks for sharing this description of your approach. This sounds very interesting.
Andrea Tomasini, CST,CSC,CSP,CSM,CSPO,REP, 4/2/2009 12:45:41 PM
Thank you for having invented User Stories, Relative Estimations and Planning Poker :-) Interesting enough the JEJIT Task Breakdown, reflects the "Cone of Uncertainty" approach: the accuracy between story points in the range 3 - 20 is around 60%, which matches the uncertainty of factor 1.5 that you would have with "User Interface Specification", and if you attach to a Story some wireframe design, you are definitely in, otherwise 60% is more than reasonable. At a task level we would still be around 25% (Cone of uncertainty 1.25) so why bother in setting tasks -even if only for 10 days - in advance :-)

Best
ANdreaT
Mike Cohn, CST,CSP,CSM,CSPO, 4/2/2009 8:56:42 PM
Hi Andrea--I can't take credit for inventing any of those ideas. User Stories come from XP and its inventors, Kent Beck, Ron Jeffries and Ward Cunningham. The term "Planning Poker" was originally from James Grenning. And I think Relative Estimating has been around since the cavemen. At best, what I've done is popularize the concepts.
Andrea Tomasini, CST,CSC,CSP,CSM,CSPO,REP, 4/3/2009 3:05:47 AM
This is what makes you an Agile Leader ;-) indeed they were already there, but not in the way you brought them to us :-) and at least you put in there a lot of glue to pack all the concepts nicely together ;-) so sorry for having used improperly "inventor" ;-)
Andrea Tomasini, CST,CSC,CSP,CSM,CSPO,REP, 7/6/2009 12:51:00 PM
I published a blog post on more details on how we do Planning Just Enough and Just in Time, it may be of interest to someone. You can find it here: http://www.agile42.com/cms/blog/2009/07/6/sprint-planning-just-enough-just-in-time/

Best
ANdreaT
Rostyslav Seniv, CSM, 1/13/2010 5:59:47 AM
Hi Mike, Really nice article, thanks. I have few questions/thoughts.
I really like JiT approaches and want to clarify whether what you are saying someone calls the spike? The experiment needed to provide details to the story, that could UE as in your example, or prototyping/3rd-party verification etc. I agree spikes are sometime required, but I'm not sure why should they be done sprint before we plan to address actual story. Velocity could be broken, if we spent one sprint a day for such work, but next sprint 2 hours or nothing. Couldt hat be packed into spike stories with small sizes (1 - 3)?

One more question is whether UE guy is playing on Product Owner side or the team side? If PO - no questions, his job would be daily cooperation with the team plus creating mockups by PO request for future sprints. If not, and he is a team member, his job is just a part of a story, like Dev or QA or TW. In that case, I assume that UE was just example of more general case, so there could be situations in which it is required to spend time in advance for Dev or even QA, right?
So, we are basically spliting the story down into 'investigate (prepare)' and 'do'.

Secondly, it looks like Product Owner should be doing better job with detalizaiton, and prepare better (ready to use) stories, small enough. Planning Poker of whatever Sprint Planning 1 is should be improved too. That is time to catch 'not enough details' cases and address them.

And back to UE case. Could this guy be on a side of PO, or be a separate entity from the team with own backlog of items (mock-up for screen A, B,.. etc). During planing pokers or release plannings or backlog sizing meetings team could just link somehow their stories to UE stories. That will help to organize UE work. In addition, UE would be at some percentage team member for daily cooperations. Product Owner would be still managing both team and UE guys priorities. PO responsibility is to get portion of Produc Backlog ready for next sprint planning, he will request what he needs from UE. Similar about Architect if applicable (may be not really similar, but UE and Arch Design look to me more like requirements and not like sprint tasks). The process would be transparent and controlled, PO will request help from Architect and UE in order to prepare story for developers.

Would appreciate any comments
Ryan Garcia, CSM, 8/8/2012 10:31:12 AM
Great comments!

Mike, I have a question about breaking down User Stories.

If a User Story is too big for a single sprint, but cannot be broken down into another user story, hwo do you handle it?

Do you break it down into technical tasks (that add up to the user story) so after 2-3 sprints it will be complete??

I mean, some User Stories are simple, but require a lot of technical work that takes longer than 2 weeks. I know the standard is to break it down into smaller "user stories", but the team has found that some just don't make sense to create more user stories and just require more work.

With one of these, we had 40 Sory Points, and just deducted the points from each Sprint as we burned down the story.
After 3 Sprints, the work was complete, and considered "done".

Any comments will help!

Thanks,
Ryan

You must Login or Signup to comment.