How Do I Manage User Stories So There is a Body of Project Knowledge?

Reader Question:

“On my current project, I am getting my first exposure to User Stories. (As a..I want..So that.) With so many stories, I am wondering about managing them so that future analysts will a body of documentation to reference. Right now, we have no structure, so the list of stories grows with no real way to search them. We seem to be OK with relying on memory, and I see this lack of structure as a project risk. Any organizing suggestions? “

Managing User Stories

Adding attributes to User Stories is like adding color to these M&M’s to help in differentiating them from one another.

Anup’s answer:

I am assuming that your current Product Backlog has following fields:

  1. User Story  Title – Small title for the User Story that helps you to identify it quickly
  2. Priority – Numbered Priority for the User Story. I prefer to have the Product Backlog ordered by this field.
  3. Points – Story Points for the story
  4. Status – The current status of the Story

As you mentioned, this is manageable when you start the project, however it gets more and more difficult to manage as the list grows. Consistently grooming the product backlog is very important. What I have found to be very useful is to add some more identifiers for each of these fields. This provides more control over the list.

Let’s look at few examples.

Severity (or you can call it Priority Group):

Values – Critical, High, Medium and Low

I use Severity with Priority to keep the focus on high priority user stories.  Adding stories is a continuous process, and it may not be feasible to assign a priority as soon as you add a story.  At the time of adding a new Story, I ensure that I assign a value for Severity even if I am not able to assign a Priority. If I am not able to assign a Priority then I just use 999 to identify that a priority needs to be assigned later. (Yet to cross 1000 in any single project.) Every week, we have a priority meeting where we sort the Product Backlog by Severity and then by Priority. This gives me a good starting point to concentrate on the Criticals and Highs. In most of the meetings we run out of time before we reach the mediums and lows and only look at these when they become Critical or High.

It is very important to clearly define and explain the values for Severity and ensure that it is used correctly. We generally have a product milestone of 4 months. Each milestone is defined as to what we want to achieve in that timeframe. Let’s say, for an e-shopping site the first milestone may be that customers can register and browse the list of items but cannot order the items. For the first milestone each story will be categorized as per this goal. So Customer registration form will be Critical but Credit Card payment will be low.

Story Group

Story Group is linked to Story Title and helped me in grouping the stories. For example, some of the Story Groups for e-Shopping site can be Customer, Products, Orders, Order Fulfillment and Reports.

Story Groups helped me to look at the product backlog from a different perspective. Generally we work with different business groups who were focused on a certain aspect of the application only. At times, it became important to filter a product list and evaluate what are we left with in a particular group and tweak the priority of the stories accordingly. Though our eyes are always set on the milestone but it was important to focus on parts of the application to ensure we are not missing anything. One of the interesting outcomes was that we identified some duplicates and were able to weed them out.

We also ended up creating reports for the executive management by Story Groups which gave “just enough” insight to them.

Status

When we started our Scrum Project, we started with basic statuses of Not Started, In Progress and Done. However, we realized the need to break it down a little further to provide more insight on where it stands. That helped us identify bottlenecks early enough to avoid undesirable impact on the team velocity. The decision to break it into different statuses is very dependent on the team structure and the processes followed. I don’t recommend breaking down the statuses if they don’t add value. The idea behind Scrum is to keep the process overhead as lean as possible.

As an example, we broke the statuses to: Not Started, Requirements In Progress, Requirements Done, Dev In Progress, Dev Done, UAT In Progress, Done

Dates

We also added dates for these Statuses. These were formula driven and were auto-populated as soon as we changed the Status. It is nothing very fancy and we used simple Excel formulas to manage the Product backlog.

The dates were mostly used for tracking and analyzing the turnaround time for various activities. I remember, at one point it helped us to clearly show that the UAT was not keeping up with the development and could cause delay in the final release. This helped us to get necessary executive attention on the issue.

My overall recommendation will be to stick to basic structure as far as possible and only add these or any other fields only if they make it easier to manage the list. Don’t add all of the fields in one go, add them one by one and see if you need the others or not. Only add more fields if you think they will add more value. Also, don’t shy away from getting rid of them if they are not useful anymore.

>>Read Some Related Articles

Click here to learn how a feature map can help you keep track of the big picture

Click here to read about how technical specifications and system documentation can take different forms

Click here to read about the positive influence BAs have on the quality of documentation on agile projects

>> Learn More About Agile Requirements

Check out the Agile Track of Crafting Better Requirements, a virtual, instructor-led course that will also earn you 21 PDs or CDUs. You’ll learn about how to create a product backlog, turn stakeholder needs and wants into user stories, and create acceptance criteria to support testing.

Click here to learn more about Crafting Better Requirements – Agile Track

Stay informed about new articles and course offerings.

(You'll get a free step-by-step BA career planning course too).

Click here to learn more

your details are safe with us

Books and Courses You Might Be Interested In

Comments

  1. What about dependencies? When one user story cannot be done before implementing another user story…

    • Anup Mahansaria says:

      Nick, you bring up a great point.

      There can be quite a few ways of handling this depending on the overall project and how often you experience this in your project. In general, the dependent stories will be prioritized after the stories it is dependent on.

      I have used a couple of ways to handle dependent stories. My most preferred way has been to keep the status of the dependent story as “Impeded” with a note that states which stories have to be complete for the story. The priority was always kept independent of the status. If the priority of this story was moved up, it was an indication that we should change the priority of the stories on which it was dependent.

      As I mentioned depending on the story in question, I have also used other ways to handle it. At times, I have merged it together as one story or sometime treated it as stories under an Epic.

  2. Interesting article, thank you for posting it!

    I have some questions, and I’d like to share my own experience with how my group manages stories for later reference:

    Would you elucidate a little more on how dates, status or severity help assemble a Body of Knowledge?

    To share my experience with structuring stories for future reference, we use “project” and “tag” fields to help group stories together, regardless of their implementation date or status, or their severity / priority (tho we certainly track these with our stories!) If I’ve interpreted your article correctly, the closest correlation seems to be your description of “story group”.

    This practice helps mitigate the risk of relying on our future analysts’ guesses on keyword searches, and groups related stories even when they’re not part of the same epic.

    My org uses Rally, though I’m sure many tools have similar functionality in this regard. One colleague’s group uses similarly colored sticky notes or puts the notes into a common ‘project’ folder once complete.

    We also sometimes use Microsoft’s SharePoint as a central repository in the event we produce documentation outside the scope of a traditional user story (only when the team determines it’s absolutely necessary, of course, according to the Agile Manifesto!), and include a “card catalog” list of stories that touched a functional group.

    I’m sure there are many ideas for grouping stories into an enduring Body of Knowledge – I look forward to suggestions from your other readers!

    Thanks again for a great read!
    -id

    • Anup Mahansaria says:

      Inger, thanks for taking the time to share your thoughts on this topic.

      I am so glad that you mentioned the use of colored sticky notes. Did you observe the analogy between sticky notes and M&Ms?

      Project, tag, module, functional group etc would all fall into Story Group. I wanted to use a very generic term to avoid limiting the idea to the general application of any of the other words.

      Thanks for bringing up the topic of tools too. I have personally not used many tools but I think the basic idea of using some identifiers remains the same. What identifiers you choose will depend on your project, team and other factors.

      I chose to use the term “Body of Project Knowledge” (not “Body of Knowledge”) from the perspective that all these identifiers gave me a better picture of the project.

      We started our Scrum project with the basic product backlog. After few months into the project, what we had was a list of stories with their status. As the list of stories grew, it became difficult to take the 20000 feet view of the project. Most of these attributes were a result of addressing this need. Another problem we faced was reporting. People who were involved with the project had a good idea of where we stood. However, it was difficult to provide meaningful information to people who were not directly involved. Especially, the next level of senior management.

      Story Group, Severity, Status and Dates together gave us enough information to manage the project and report the project status to a larger audience.

      Thanks again, for sharing your experiences. I am also eager to hear suggestions and experiences from other readers.

  3. So this is what i have been doing Anup, we dont have any tool to manage the user stories but a sharepoint site to manage project artifact. We capture following for user stories:
    1. User Story ID(System generated)
    3. Epic/MMF(if this story belongs to an epic or to a Minimum Markatable feature group)
    4. Story Description
    5. Success Criterias
    6. Priority
    7. Penalty(What will happen if this story is not delivered)
    8. Dependencies(Dependent stories)
    9. Story Point
    10. BA responsible
    11. Stakholder responsible
    12 Status(draft, approved)
    13. Link the relevant use case(if ur writing one..this happen in distributed env)
    14. Link to Design (wiki or the doc for this story)
    15. Link to test script
    16. Spint(Sprint in which this will developed)
    17. Release( and the corresponding release)

    These are lots of fields .. but helps to manage the entire requirement package at one place and helps in requirement tranceabilty as well..and in case people reading this are scared..all the fields are not be filled by the BA but by the respective team members.

    thanks for the nice article and wonderful discussion.. :)

  4. Last week we launched Maelscrum here: http://maelscrum.com (The paint on the website is still wet – we’re building video tutorials for the tools right now.)

    The tool does basic Scrum management but is particularly focused on the management of user stories and requirements. There is dictionary feature that manages a glossary of terms, data item definitions and usage of both through requirements, stories, scenarios and tests.

    Export your stories in BDD and xUnit formats too.

    Stories can also be shared with another tool, Business Story Manager: http://businessstorymanager.com so that your stories can be shared with legacy/structured projects – and vice-versa.

    If you want a hierarchy feature, the requirements hierarchy can be used to capture epics in a tree structure. If you are interested in mapping features to workflows, you might be better off looking at Business Story Manager. It captures processes, process elements and you can create process paths with steps to map to features, scenarios and even down to example row level.

    Take a look :O)