Kick-starting a backlog

Another one of the “so I don’t forget” series.

We had a session with some stakeholders this week — to start a product backlog.

Purpose was to create an initial backlog big enough to cover the following 2–4 sprints.

Damien started by presenting the purpose, and asking participants to present themselvs, and their expectations from the workshop.

Next, we described shortly the suggested format (as explained below)

And then the fun begins !

Gather features:

  1. All participants were asked to write on a postit (the Agilists ultimate tool ;) The SINGLE most valuable feature they would like in the product.
  2. All postits were explained briefly and merged (if needed)
  3. All postits were broken down to the smallest features that still bring value using a different color postit. (and we marked some id on them to link them to the parent story (Epic)
  4. Next we repeat step 1, for any missing feature (and repeat steps 2 and 3)
  5. Next we ask if anyone has a feature they think are more important than the least important story (in her/ his eyes), and repeat the process one last time

Now we have a list of the most important features!

Prioritize:

We layed all the feature cards on the table in a random order, and ask the team to (silently!) take turns in switch the order of two cards (bubble sort) until a reasonable order is reached. 

Storyfying the features:

  1. We took the most important story, and ran a small workshop to understand
  • Who is the story for
  • What is the addressed need
  • What is the expected benefit
  • What is the proposed solution
  • What would you expect to see in a demo?

    (Or, in otherwords — make a Story out of the selected feature)
  1. We distributed A4 papers, split the team to three (we had two BAs in the sessions to help) and asked each team (in a timeboxed manner) to take one of the three first features and:
  • Write the story on a page. (as described above)
  • Present the story to the team (and modify accordingly)
  1. Then we took the next three stories and (rince and repeat… — well — you get the idea!)
    (One thing we forgot to do is change the teams each iteration (some teams are slower/ more theril, others are faster/ shallow, we want the team to evolve…))

Sum-up

We explained that:

  • The backlog is a living document, so priorities can be changed, and stories can be added/ removed/ changed all the time (except if they are in the current iteration)
  • Other stakeholders will intervene and add their stories, so we need a mechanism to shre priorities with other participants (and it is the role of the PO to facilitate this process)
  • We don’t have any estimates yet, but we will update the stakeholders once we start having them.

Wrap-up

  • We received a great feedback
  • The only regreat is that not all relevant stakeholders were present.

Hope you enjoyed reading my note! ;)

The Scrum ’em bear.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.