Projects' Little Helper

I was once asked to draw up some guidelines to help steer a team through starting up an agile project. They wanted to have a clear understanding of what was needed to create their initial product backlog. So I fired up Omnigraffle and came up with a few pages that gave an outline for that particular team.

The 3 page PDF covers the following.

• a page with a summary of the phases involved in the process of Product Backlog creation
• a basic Flow diagram, that you can see above
• a page with descriptions of some potential roles/capabilities.

IMPORTANT! – this is a guide only, not a template. It was created for a particular condition, and it should be assessed and adapted to your conditions. I have adapted it slightly and posted it here in the hope that it might be useful if you want to give someone an overview of what starting up an agile project might look like, or to help you if you want to get an idea of what might be involved.

Whatever ends up being right for you, the emphasis should be on communication…doing the right things at the right time, for the right reasons; and making sure that the right people are involved at the right time.

The Phases of Product Backlog creation

Here’s a short description of the phases that are included in these guidelines.

Theme ordering/priority

With Product Backlogs, we often talk about the different items as User Stories, Epic Stories, and Themes as a way of helping to organising the different things that a user would do in a finished project. Some people think of Themes as “collections of user stories“. This is OK, however I have tended to think about Themes as high-level categories from which smaller user stories will be created. At least before many/any User Stories have been created.

For example, “We want to Browse for products, Search for products, See Detail about products, Compare products, Select products to buy, and Pay for them”. So in this case, Browse, Search, Detail, Compare, Select, and Buy, would be the Themes. Some of these we want to do first, or need to do first. This is known as Ordering. It has been known as Prioritization but that Ordering is now the more accepted term. We’ll take the Themes that we want to work on first, and break them down so that they can be developed. Some of the themes won’t be done for a a while, so we can put them aside for now.

Phase 1 – Story Creation

Our goal in this phase is to come up enough User Stories to be able to take them into development and come up with an increment of our product that is tested, working, and might be something that will be usable. Sometimes, there will be some User Stories that have emerged already, sometimes there are just the high level umbrella themes. In this phase let’s get more User Stories out there that we might want to work on imminently.

Phase 2 – Story ordering

We talked about ordering Themes earlier. In this phase, we are talking about ordering the stories that we came up with in the previous phase. It could be that our creative juices flowed so much that there is more work than can be done right away, or that we’ve come up with stuff that we definitely can’t, or don’t want to implement right away. This phase is about surfacing the things we definitely want to take froward and elaborate on in the short term. We’ll put the other stories aside for now.

Phase 3 – Acceptance Criteria

Now that we’ve go the likely candidate stories, let’s figure out what it would mean for the story to fulfil the needs of the user. This is stuff like “I typed the term ‘AA Battery’ into the Search box, then clicked Search. The results would come up in alphabetical order based upon the product name”. There might be several of these Acceptance Criteria, which are sometimes known as “Conditions of Satisfaction”

Phases 4 and 5 – Prototyping and Front End

Even if we have a User Story or three, and some Acceptance Criteria. In order to actually work on it, the team will often need to know more. In Extreme Programming (XP), the information would be communicated with face to face conversations with the customer at the time of implementation. In these guidelines, I show some other inputs that might help the team to implement the stories effectively. In this case, prototyping was used to help to add understanding in the team about how the stories would work when implemented. The User Centred Designer would also work with the Front End Developer who would produce front end code that would be passed to the the developers.

Phase 6 – Bundling

This is simply, making sure that everything is together and at the point of readiness. We don’t want to start developing the stories, only to find out that some of the info that is needed, hasn’t been done.

Download and related post.

PDF

Product Backlog Creation guidelines (288kb)

Related post

Creating a Product Backlog: Story Mapping. I also have a post about Story Mapping, a Product Backlog technique that I think is useful. It also talks more about the concept of having enough detail to work from for upcoming work, but keeping things at a high level for work that won’t happen for a while.