You are here

Creating your Initial or First product backlog (Backlog Items)

Body: 

Creating the Backlog Items.

This builds on the previous article you can find here
In this session we will

  1. For each user
    • review the goals and needs we defined in the previous session
    • expand these goals and Identify the features that support them, all the time focusing on business value.

    For this we need the same team we have in the previous stage, but expanded in a few areas.

  2. We need to bulk out the User representation with a few more real users.
    • In addition to the product owner,
    • We need at least 2 or three additional users.
  3. If you have specialist needs along the lines of
    • Management Information,
    • Governance,
    • Architecture,
    • Statutory requirements, make sure you have somebody that can represent them along as well.
  4. You should also have as many of the development team present in this session as possible.

Granted, this is expensive but it is also cost effective.

The format we are going to use to document the backlog is the user story format. It is by no means the only format that can be used, but is definitely the most commonly used, and almost universally understood.

Before we get there though it is well worth highlighting a few specifics from the Scrum Guide and the principles behind he Agile Manifesto. For me, at this stage in the game, two very key principles behind the manifesto are:

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Simplicity--the art of maximizing the amount of work not done--is essential.

And paraphrased from the scrum guide ‘2013’

  1. The Product Owner is responsible for:
    • The Product Backlog, its content, availability, and order
    • Maximizing the value of the product and the work of the Development Team
  2. The Development Team
    • creates the product increment without external interference.

With this in mind, I tend to take the traditional:
As a: < user/role>
I Need: < Feature or function>
So That: < I can address a valuable business need>

And move the business need to the front. In other words use the format:
So That:< I can address a valuable business need>
As a:< user/role>
I Need:< Feature or function>

Sure, it does not roll off the tongue as easily, but it is important to make sure have the correct focus. This forces us to focus on the business value that the role needs to provide and then the functions to support them. When the I need: precedes the business value So That: it is very easy even for and experienced team to fall into the trap where rather than addressing value you tend to define solutions and behaviour.

In other words rather than
As a: Sys Admin.
I Need: Password protected access to the system
So that: I can restrict access

You have
So That: I can comply with data governance access requirements
As a: System Admin.
I Need: To have the ability to restrict access to the system by user

The value here is clearly making sure that access to the system maintains compliance with data governance. Not the fact that access is restricted by a password. After all, access may be restricted by many different means, smartcard, biometric and a host more.

The difference might seem subtle but it can have a far reaching impact What this does is make sure that the focus is on the business value or the goal we are trying to achieve, rather than the functions or features we are going to make available to achieve those goals.

Ok, What else makes for a good user story. It is generally accepted that if you focus on the following 6 attributes you will go a long way to achieving good workable user stories.

  • Independent
  • Negotiable
  • Valuable to users or customers
  • Estimatable (Not a real word, but we all know what it means)
  • Small
  • Testable

    This is the invest model that is described all over the web and in the book ‘User Stories Applied’ by Mike Cohn. The relevant chapter of this book is available from his web site and can be found by following this link
    One thing to note about the <I>ndependent in then INVEST model. The independent means that it should be something that can be built independently. It does not means that it needs to be a completed independent feature, it need not even be useful without other pieces of work being completed. It must be a potentially shippable artefact that can be included in the product increment at the end of the sprint, and not break a release.
    That is enough prep work let’s actually do something.
    We start by taking each of the goals we identified in our earlier session and break them down into smaller pieces of work. The features the Users need to address their goals and the work the team needs to do to create those features. Brainstorming techniques work well for this. The idea is not to go into too much detail and not to get bogged down. Try and keep the session flowing, if you come across a sticking point, put the card to one side and keep going.

    1. Each attendee independently creates story cards targeting a specific goal. These can be features, or pieces of work, Remember your first stories will take a lot more time than you want them to.
    2. Spread the stories out on a large desk or table and as a team group them, combining duplicates, discarding obviously un-needed or unimportant work. Have a single person facilitate this, it works much better.
    3. You may find that this exercise highlights a few new stories, create them immediately and add them to the rest.
    4. At this stage you will find that some stories easily fall into the INVEST model, but a lot of them won’t. Don’t worry too much about that now, but at least make sure that you have features that address each of the goals the users identified in the previous session.
    5. Once you have cleared one goal, move on to the next one and start at the top again.
      Once you have run through all the goals,
    6. Make another pass through all the cards and make sure that they make sense on their own and contain a valid business need (So That), Target User (As A), and feature/s to address that need (I Need).
    7. If needed, combine, amend or splint them to get closer to the INVEST model as described above.
    8. At this stage it is often useful to group stories into Themes. These could be User, Organisational Unit, Related features or anything that will help both the PO and the Team make sense of the backlog. Some would go as far as creating summary cards, but unless you are going to move the cards into a tool, I would resist the urge.
    9. For those cards that are obviously on the large side, make an initial stab at breaking them down into smaller pieces of work. Again remembering the INVEST model above.
      Then, if time allows,
    10. Pick up any problem items you have put aside and clearly identify the sticking point, then if you can, resolve it, or take it outside the meeting to clear up.

      That’s it then we now, have the bones of the backlog but are missing a few key things (Order, Value & Size) that we will address in the next session.

      Find the initial article here