Take a minute and think about your current backlog. Close your eyes and get a good mental picture of it. OK, got an image? Now open your eyes. Does it look something like this cluttered garage?
Or, maybe you think it’s a little more organized and looks like this garage:
Either way, all of your stuff, your requirements, your backlog items are stuffed away and it’s probably hard to figure out what you’ve actually got. You and your team probably spent a good amount of time in a planning session writing as many user stories as you could think of. And, that’s not a bad thing to do during the initial brainstorming sessions when you’re stocking your high level backlog. But, at this point, you haven’t pared it down to stories that fit the overall vision and roadmap for your product yet. The backlog at this point is cluttered. Because it’s so cluttered (or put into neat little boxes or files or binders), it’s really difficult to make connections between the stories. It’s hard to see the big picture. So, what do you do now?
Well, Dan Roam, author of The Back of the Napkin has a good solution. Have a garage sale. Well, sort of. Dan talks about the Garage-Sale Principle. He says:
“Regardless of how well organized all the stuff in the garage may be, laying everything out on the tables in the light of day yields a completely new perspective on it all.”
So, how can we do this with our backlog and our user stories? First, get all of your stories written on cards or really big sticky notes (preferably during your initial planning session). Now, get a conference room and stick all of those stories on the walls. Plaster the place with them . Next, let everyone on the delivery team, all of the stakeholders, the product owner…everyone…take a walk through the conference room. Leave the stories up for a day or two. Let people really get a good look at every story. Give the team a place to air their comments about the stories. And then, start performing story triage.
Start by grouping the stories based on two or more of the 6 W’s: Who, What, Where, When, Why, and (W)How. And I mean literally group them on the walls. Move the stories around. Let everyone move the stories to the groups they think they belong in. Got them grouped? Good. Now, go through the groups and the stories and start moving any stories (or entire groups) that don’t adhere to the product vision or roadmap into a parking lot area somewhere in the room (but don’t throw them away!). Be tough and cut any stories that don’t advance the product vision. By now, you should have user stories that are grouped by common themes and that are completely focused on achieving the product vision. You’ve cleaned your cluttered garage and now you can clearly see the value of all of the items that were in there. Now you’re ready to start moving stories into your backlog and get to work building focused, valuable software. And, because your team and product owner spent a little time living with their user stories, prioritizing and sizing the stories in the uncluttered backlog should be easier too.
Related posts:
- What are you waiting for? Dave Bouwman and I had lunch with some friends...
- Know Your Users In agile software development, we create user stories as a...
- Is Iteration Zero a good idea? As I’ve been contemplating moving agile throughout our entire...
- What’s in your backlog? This morning I was looking over several of our project...
- Get Smart: Storyotypes in your backlog As I’ve been looking through backlogs from various organizations and...
Related posts brought to you by Yet Another Related Posts Plugin.
5 Responses
November 3rd, 2008 at 4:45 pm
Hi Chris
To simplify our backlog we use a combination of parent/child relationships and MoSCoW ratings
MoSCoW (Must, Should, Could, Wont) ratings are a high level rating that lets the business define how important the user story is. Using filtering we can hide all the user stories that are not rated as “MUST” and then we can easily see what we need to start thinking about.
Using parent/child relationships we can expand and contract the backlog to either see lots of detail through user stories or a high level features as parents.
Pat
November 3rd, 2008 at 4:54 pm
Usually and theoretically a weekly meeting with the Product Owner for this purpose should do the job; but in real life, a high percentage of the projects encounter this problem, mainly because of a lack of availability of one or all of the participating parties.
I haven’t found a perfect formula for this but, here it goes:
Along the already started SPRINT (or iteration) I do 1 or 2 meetings a week with my Product Owner (or group of people that represent it) and we do some TRIAGING over reported bugs and improvements (always leave a % of the iteration for this kind of work…which will vary depending on what moment of the entire project you’re at).
New things may be included into the SPRINT but we try to stick to the scope we committed to in the Planning Meeting at the beginning of the iteration to reduce risks. This can be followed mainly when the iteration is less than 4 weeks long. I try to follow a 2 weeks minimum and 4 weeks maximum SPRINT lenghts.
Now, there will be new things that where intended to come into the SPRINT, that after some current SPRINT impact analysis were decided not to, but still wanted for future iterations; and there will just be new stuff that goes directly into the Backlog.
Either way any new inclusion implies impact analysis (time, cost, quality, architecture), and according to that we need to do TRIAGING (exclude this to include that) or contract revisions to increase/decrease cost, backlog (scope), human resources and time; or just change some of the backlog (scope) if the other variables maintained.
In these “impact analysis” I mention so much, the participants may vary depending on what’s at stake; Meaning… QA, Software Architect, Lead Developer, etc etc…but always at some point the Project Manager (or SCRUM Master) and the Product Owner.
Then, towards the end of the SPRINT, more specifically the last week, the focus of these meetings need to take special attention to what’s going to be wanted for the upcoming iteration, which is basically a game of setting/changing/moving the priorities of what’s in the backlog (this includes TRIAGING of course). This way when the SPRINT finishes and it is time to plan for the new one, we’ll already have a more mature idea of what we need to estimate, sub-task, etc, and big changes along the iteration will be less likely, as we want to.
The bottom line is that this needs periodical (at least once a week) revision between the Project Manager and the Product Owner, which may lead to other steps before briefly mentioned.
November 3rd, 2008 at 11:26 pm
I like Patrick’s idea, and will present it to my Scrum Master User Group at work to see how they like it. Our current prioritization scheme could use a shot in the arm…
I will add that one of my product teams maintains a separate backlog called the Graveyard, “where stories go to die.” I am presuming that once something gets buried in there, it stays buried, but zombies might drag themselves out into the light of day.
Of course, needed a graveyard implies you have a lot of bodies to dispose of. So it’s a sign that at one time your backlog was cluttered.
November 4th, 2008 at 1:16 pm
I had many problems about to control the scope, after many attempts I decided use Control Point, every moment of product development I testing with the sponsor or the stakeholder about the vision of the product.
After this I get more successes in my projects.
November 4th, 2008 at 1:45 pm
Chris,
What I’ve usually seen and what probably makes more sense is to ‘track’ the user stories via themes or ‘categories’. These could be based of the user defined deliverable chunks of requirements categorized appropriately or grouped as deemed appropriate by their common business functionality - not completely user driven but rather by the analyst.
Would you know of any other better and practical ways to do this?
Thanks,
- Asha
Leave a Comment