The Nokia Test (5): A prioritized Product Backlog is essential

We started a series on The Nokia test some time ago. This is the fifth explanatory post about the test. To find the others, search above (left). And here is the original post.

The second item in the second section of the Nokia Test is this:

• There is a product backlog prioritized by business value

Seem obvious? Well, maybe you don't want to say so quickly.

First, if we are doing Scrum, we must have a Product Backlog. A Product Backlog is a list of all the work items the team is expected to work on. If the Team is doing software, most of them will be features at a high or low level of granularity. In Agile, the growing preference is to put these Product Backlog items in User Story format.

This part of the Nokia Test does not require you to use the User Story format. Or any particular format.

"Prioritized": Ummm. What does that mean?

Well, I think it means that the Product Backlog has been put in order of Business Value.

The Nokia Test does not give us any hints about what Business Value is. My opinion is that this itself is a complex topic. But I think the implication is that the Product Owner (who owns the Product Backlog, and makes all final decisions about it)...the Product Owner will put the items in business value order.

Does the test imply that Nokia always wants to work the highest business value items first?

This is open to some debate. My view is that one can still pass the test if one also uses "cost" (or story points as a proxy for cost) and dependencies/risks as additional factors (bits of information) in helping the Product Owner to order the work.

Let's put this some other ways.

The technical team does not have the final decision about what order to do the work in. Sometimes it is better to be inefficient and get some high Business Value item(s) out there in production.

Since all Product Backlog items are not of the same size (let's call this "amount of work" for now...although one must tread carefully here), and not of the same Business Value, the Product Owner must do cost-benefit analysis to determine (implicitly at least) business value per unit of work for each PB item.

Why do we prioritize by business value? We are always trying to discover and release business value (eg, increase customer satisfaction). Quickly. Only if we use Pareto's 80-20 rule can we do the most important stuff first. Ordering the PB items puts Pareto's rule into play.

And I think the Nokia Test says the Product Owner cannot cop out and say each PB item has the same amount of Business Value.

Similarly, this part of the test does not prohibit some team members (developers), where they have useful knowledge, from influencing the Product Owner about business value and about the order of the work. (Still, Scrum says the Product Owner gets the final say.)

* * *

Well, that's a start on the implications from this one part of the Nokia Test.

Please see our other posts on the Nokia Test.

Note: The picture of the story card above was stolen from here: http://www.pragmaticsw.com/newsletters/Newsletter_2008_05_SP.htm

What's a team?

Let's review what a team is in Agile.

A small group: 7 plus or minus two.
Motivated by the vision of one person.
Dedicated (ideally 100% but certainly a lot).
With almost all the skills needed to realize the vision.
The team works together daily.

A team is not:
* Lots more people than that (that's a collection of people).
* Motivated by multiple visions (if there is some similarity in the work, that might be a department).
* Following multiple people (that would be confusion).
* Some folks who work together from time to time.

We give a Team a mission, and we expect them to figure out how to deliver it.

For an interesting discussion about how small teams work in warfare, see Maneuver warfare.

Why are teams important?

This may seem obvious to many of you. But even for those, it may be useful to review.

1. No simple problems. We now need a team to figure out almost any problem. We need the knowledge from multiple people.

2. Creating knowledge. The team is the unit that creates the knowledge. The convert tacit knowledge to explicit knowledge. They brainstorm. They convert ideas to something more real, and examine whether they are achieving the vision.

3. Has "it". We can't describe everything that makes a winning team. One day knowledge. One day skill. One day motivation. Every day something different. But they get it done.

4. Motivation. Creating something brand new is hard work. The team members need to motivate each other to get past all the problems and issues. The team has to find its heart. Once it has it, you can let it run.

5. Clarity. If we have a real team, then when we examine what it produces each Sprint, we have clarity about that. The problems are much more obvious. There is much less confusion. The best actions to make further progress are clearer.

6. Fundamental to make Scrum work. Scrum is built upon a team concept. To get the real value from Scrum, you should start with a team. (I have not thought about it as much, but I think this would apply to all or almost all of Agile.)

* * *

Is your team reaching its potential now?