Creating the Backlog Items.
This builds on the previous article you can find here
In this session we will
For this we need the same team we have in the previous stage, but expanded in a few areas.
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:
And paraphrased from the scrum guide ‘2013’
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.
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.
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