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

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.

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.

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