Release Planning: Product Backlog

[This post is one in a series on Release Planning, which starts here.]

After we complete the Vision, we must develop the Product Backlog.

There are two parts to this.

First, we must define the Roles to use in the User Stories.
Second, we must write User Stories.  I call this second part a User Story Workshop.

Let’s break this down.

Assumption:  We have a new team that is doing Agile-Scrum for the first time.

Who: We want the whole team of pigs (PO, SM, and implementers) and the BSHs (business stakeholders).  Usually you want the 3-5 best business stakeholders you can get.  The Product Owner is usually the main person driving which BSHs to bring in.

The Product Owner is leading the content. The ScrumMaster is leading the facilitation.

What: We want about 5 to 7 roles. These are the roles to use in the User Stories.

The other key input is some understanding of about six months of work for some good release planning.  (In some situations, we want or have more or less work.)  Often the group got a basic understanding via discussion in the course of building the Vision (the prior task).

So, in about 5 minutes, the group identifies a good list of roughly 5-7 user roles (actors, personas).

How: Brainstorming to get 5-7 roles can be easy or hard.

We mostly want different user types (roles), end users of the system or product.  Generally, we want any role that wants a feature in the product; even if that role doesn’t (directly) use the product.

(Note: These are not the roles of the Scrum team members. A fairly common question.)

Some teams will come up with 30 roles. Some will come up with only 2. We want to either synthesize or break down the number until we get to the 5-7 range, or closer to it. Something magic about that range, but not worth dying for.

Now we are ready for the next step, the user story workshop.

If we have about 6 months of work, let’s do some math.  My rule of thumb is 8 stories per 2 week Sprint.  6 months work is 13 sprints.  13 x 8 = 104.  Now, those stories would all be small enough for a Sprint. So, in Release Planning, we can be pretty happy with 50 stories (average about twice as big as a Sprint-sized story).  This gives us a rough idea of the number and size of stories we will be shooting for in the user story workshop. Of course, we will learn a lot later, and can make many adjustments.

Thus, we only need about 50 stories that cover about 6 months worth of work. (The 6 months is only a gut feeling; we have not done any story pointing yet.)

Whatever stories they will write, the stories will probably work well enough the first time. It will become better as they practice with stories, and appreciate tacitly the characteristics of a good story.

Now, with the Roles, the whole group starts to write stories. We let them self-organize.  We give them 15 minute time boxes.  At each 15 minute break, they “check in.”  They inspect progress and see if they want to adjust anything. Usually they see that they want to write stories faster.

Typical productivity for a team is that they will take 2 or 3 timeboxes to complete almost 50 stories.  About 30-45 minutes.

The stories are not perfect, and there may be some duplicates.  Useful work done quickly.

Some times might get this done in less than 30 minutes, and some may take longer than 45 minutes.  Do not let them take longer than 75 minutes.  It is very unlikely to be a good investment.

When they feel finished, we recommend having the whole team gather around all the stories (imagine them on a wall).  They should look at them, and try to see what needs improving the most.  Maybe a few aren’t worded well.  Maybe a few need the INVEST criteria a bit tighter.  Maybe a few are missing the ‘so that’ clause.  Maybe two team members identify 3 missing stories.

What were the INVEST criteria?
* Independent (we try to maximize this, but we never can make all stories independent)
* Negotiable
* Valuable
* Estimable (clear enough that we feel effort can be estimated)
* Sized Appropriately
* Testable

It is sometimes useful to get more sophisticated.  I don’t like to do that the first time.  They need to get one cycle of just doing the basics.  Probably several cycles.

We recommend that the PO answer questions and talk about the product that he envisions. But let the everyone identify the specific stories.  He gets them more engaged. They get more creative. They have better motivation.  The PO can always add or modify later (if their work is imperfect).

Since this is a question that often comes up, let me say this clearly.  We do not want the PO writing all the stories. This does not help and it actually hurts the Team. We want the engagement high.

Why?

Why do we have all the pigs and the business stakeholders?
Several reasons I will mention.

1. We want the whole group to share whatever tacit knowledge they have with the rest of the group.

It turns out that everyone has some knowledge or ideas to share. Or at least some good questions. Well, almost everyone (yes, there are a few exceptions sometimes on this one.)

2. We want the group to create knowledge together and share it together.

A bunch of things happen as they create knowledge. One is that they all start to form a similar mental picture (or pictures) of the product and the effort and things related to it (one example: the architecture).

3. We want the team to develop motivation together.

Finally, having been involved in the creation, the whole thing becomes their ‘baby.’  This is far better motivation than we get from ‘the mushroom treatment,’ which is de facto the most common thing. (The mushroom treatment is where the team is kept in the dark and fed manure — this is great for growing mushrooms, not so great for growing teams.)

Yes, it is somewhat expensive to have everyone involved.  But the payback during the project is very high.  Very high.  The time to market is better.

Time Box: As indicated, I like to have a series of 15 minute time boxes, where the team checks in. Are we going too fast or too slow?  Anything we should change? Who is talking too much, who too little?

Usually the whole thing can be done in 30-45 minutes.  Really it is not a big problem if it goes to 120 minutes. The main thing is, as SM, if one guy gets talking and worrying, and nothing is getting done, you can’t let the team just spin.  Someone must fix it, and get them productive again.

Common Issues

I like brainstorming rules. Meaning: Anyone can create anything, write any story, and for this time box (say, 15 minutes), no critique is allowed. Then an editing or ‘fixing’ time box can happen later, where the team reviews and improves the roles or stories.

I find creating one story and then criticizing each one is too slow, and inhibits the team too much. Especially beginning teams.

Another issue is having only one person actually write (scribe) the stories. If a team really wants to do this, it is not terrible. But things usually go faster if everyone writes. Or more people write.

Not sharing. I think it is useful if, as a person writes a story, he shares it with the group (says the words of the story out loud). That way, it is less likely that someone will write the same story a second time.

Top Down/Bottom Up.  I find some people are top down thinkers and others are bottom up thinkers. It takes both kinds. Let them be who they are. Especially while they create.  Rather obviously, top down thinkers will tend to write epics that need to be broken down (even at this point we can often see some epics are just too big).  And bottom up people will write stories that sometimes are small.  Sometimes maybe even too small.  We may need to ask them to write slightly bigger stories, but often it is ok.

User Story format. This is: “As a <role>, I can <do something>, so that <why>.”  I like it and encourage it. They especially tend to forget the “so that” clause. So I encourage them to include it. But, if they just can’t think of the feature in a user story format, I say: ok, just write something as a PBI (product backlog item). Maybe later we will convert that into user story format.  Be easy on the beginners. They are just learning to ride the bike.

Results.  Usually the team ends up with 42-50 stories that represent 5-7 months worth of work. Ballpark.  (It is just a gut feel at this point.)  Which is a great start for the Release Planning. For beginning teams, try not to let them to go above 50 stories. (I will explain why later.)  But use common sense.

These user stories (or PBIs) are just the right middle level of ‘features’ for everyone to have a clear enough picture of what the product will be. It embodies the vision. It makes things concrete for people, without getting mired in details. Wonderful.  And they can do this the first time.

Is it perfect? No. Could it ever be perfect? No. Is it a reasonable time to spend to get a level of ‘quality’ (in all aspects) that is very useful?  Yes!

Can we write more stories, if we discover them, later in Release Planning? Yes! And it always happens!  Also, can we add more stories as we are doing the Sprints? Yes, always.

Enough for today.

Comments?

 

« « Referral Program || Agile Principles and Values » »