Week 2: the list of requirements aka the backlog

This post is part of the series “Z2A: From zero to agile”.

What? The backlog

Enter the second week: the next action I planned was to prepare the project backlog.

A backlog is just a prioritized collection of things to be done, all aiming to the project mission / goal.

Are these things the requirements? Not only.

The backlog is not (only) the list of requirements  – nor the classic requirements specification document – but a list of topics to be discussed during the project lifetime. It is a list of all features, functions, technologies, enhancements, questions and bug fixes that could be possibly of value for the project goal.

It’s quite funny that many companies, especially the big ones, have a project portfolio – a sort of enterprise backlog – where different ideas for new products or services are tossed around, prioritized, shifted, removed; but no project backlog, preferring to have up-front frozen requirements specifications, making difficult to realize one of the critical agile values: “Responding to change is preferred over following a plan”.

The Product Backlog is never complete. The initial cut at developing it only lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Backlog is dynamic in that it constantly changes to identify what the product needs to be appropriate, competitive, and useful. As long as a product exists, its Product Backlog also exists.

This is a fundamental difference against the big up-front effort to lay down all the requirements and the detailed architecture. This is an agile cornerstone and it resonates also with the lean principle of “decide as late as possible”.

Who? The product owner owns the backlog

In order to unambiguously define the topics is necessary to appoint a single responsible for it: the product owner. He/she is the subject matter expert who knows what we want to realize during the project and which priority should get each topic, based on its ROI (Return on Investment). This allows the organisation to focus on the right items.

It doesn’t add too much value if the CEO (for the enterprise backlog) or the product owner (for the product backlog) alone in their offices write the topics. The management team should instead use face-to-face conversations and workshops to enable conversation, debate and discussion, to convey information and reach a shared understanding.
This is also a reason why the backlog is not simply frozen: it evolves as its topics become more clear and understood.

What do you put practically in a backlog? Stories.

The backlog is focused on deliverables (results, end goals, values, tangible objects, etc), not on work and processes.

The features you put in are described rather at a high level: usually just one sentence and often only a couple of keyword. You do not need to go into details for them. The general rule is that earlier a topic is supposed to come, more details should have. Later topics can be quite high level.

Ideally each topic in the backlog is expressed such that it has value to the users or customers of the product.
Don’t say for example  “add a password to the login process” but instead “improve security for users by adding a password“.

In order to help us focus on value, there is a way of writing items on the backlog in the form of user story, as defined by the Extreme Programming (XP) methodology:

as a <stakeholder or user> I want <goal or function> so that <value> .

In a single sentence, you get the three most important areas for any organisation: the customer, what to deliver and the value to be achieved.

Another advantage is that you can put such a simple sentence on a small card, very useful when talking to customers, not to intimidate them.

Examples:

As chief product manager I want us to create PimpMySkateboard so that our portfolio of products appeal to teenagers, not just adults.

As chief financial officer I want to reduce manual invoice work by 50 % so that we can shorten lead times and reduce the cost of the invoicing process.

As a warehouse parts responsible I want to quickly analyze the replenishment lines so that I can save time and have the current importer requisitions under control.

As a purchase clerk I want to use a bar code scanner connected to my ERP  system so that I will minimize costs and mistakes.

Note that the examples are focusing on the results but not on how to achieve them nor how to implement any solution. Note also that there are no further details.

How do you make the product backlog, which tool?

Actually it doesn’t matter which tool you use, it can be a dedicated agile tool or an excel file or just a folder containing all the cards with the user stories: the important attributes are that is easy to re-prioritize and reorder topics, and can be visible to everyone. Useful is if it allows multiple views, for example for different teams or persons working on different projects.

Now prioritize it!

Assigning priorities is one of the most useful action to do and actually each backlog shall be prioritized: it ensures that we are always doing the next most important task.

But giving the priorities is the most difficult task for the product owner, it seems: every task is mandatory and very important and it deserves the label “high priority”!
My suggestion is not to assign to the tasks priority tags such as high, medium or low but directly assign them a unique number, starting from 1 (the highest priority) and going down until necessary, i.e. the lowest priority topic.

This helps to give the product owner a more reliable sense of what is feasible: to see that the feature xy is in position 113 and therefore is coming only after all the other tasks / features have been completed, is much better than saying there are 150 tasks of ‘high priority’ and expecting they will all be realized, no matter how.

Giving unique numbers is also easier because you can compare directly topics one against another: for our mind is easier to decide between two topics which one is more important than among many.

Don’t be afraid of having to re-prioritize the backlog items if you insert in future a new feature, let’s say between the feature with priority 13 and the one with priority 14. With the modern tool (but even an old excel file could do the trick) you can easily re-order the items following the new one.

Last but not least: how to validate?

Finally, each topic should have attached how will be demoed / validated / accepted by the Product Owner. This has to be done in advance so that the team will know it.
More on this later (“acceptance tests”)

Advertisements

4 thoughts on “Week 2: the list of requirements aka the backlog

  1. Pingback: The iteration backlog and the definition of done | Look back in respect

  2. Pingback: The iteration kick-off and planning meeting | Look back in respect

  3. Pingback: Week3: iterations | Look back in respect

  4. I like the fact that you describe stories as placeholders for discussion. This is an important concept, since the stories will be progressively elaborated over the course of the project 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s