So, let’s summarize where we are so far.
The value process in agile software development projects is flawed, and the Product Backlog is at the center of it. It normally goes something like this:
Flawed Value Process
The customer has some challenges, and starts a project to address them. The project’s goals are formulated – and goals are value statements, explicitly saying what the valuable results of the project should be.
Based on the goals, the customer starts working on the Product Backlog, with its user stories. The user stories, as we saw in part one, are means to reach the projects goals, or ends. In this process, the customer assumes that the user stories she writes are necessary to reach the goals. But there’s no real checking if that assumption is true, if the successful implementation of those user stories does indeed bring the customer closer to the goals.
So this step is basically a one-way process. The goals do not change as a result of creating the Product Backlog, and alternative means (e.g. a different set of user stories) are not considered in any serious way.
Now, with the first Product Backlog established and prioritized, implementation starts with early and continuous delivery of software, checking off from the top of the backlog.
We usually are very thorough in verifying that what we implemented is actually what was asked for in the user story. So this is a two-way process, with evaluation and feedback from implementation to user story.
However, there’s no real evaluation and feedback towards the goals, the value statements! And that is the most interesting part – did we actually get closer to the goals? Ok, so we have the demo where the customer can see what’s been implemented and do some matching in her head and adjust the Product Backlog accordingly. At least, that’s what we hope, but we can’t know. So this is a very weak evaluation and feedback mechanism.
We need something better.
Improved Value Process
This is how I’d like it to be.
The customer has some challenges, and starts a project to address them. Analyzing the challenges, the customer creates goals at two levels. First, she finds out who is it that needs something to be improved, and what improved means for them. These are stakeholder goals.
The customer then translates these into product goals; qualities that the product should have in order to fulfill the stakeholder goals. Both stakeholder goals and product goals are quantified.
Next, the customer and the developers brainstorm various ideas for how to reach these goals, and evaluate those ideas up against the product goals. When we have found what looks to be the best idea at this point, that is, the idea that brings us the farthest towards the goals at the least cost, we start implementing.
Once we’re done implementing, we evaluate the implementation against the goals. What we thought at the previous step is no longer important – the important thing is, did we actually get closer to the goals, and how much? Since the goals are quantified, we can get a pretty accurate picture of where we are at the moment. Also, the implementation may show that some goals should be adjusted, so there’s definitely a learning process involved.
Now, this is all theory so far. In Part 3 I’ll show some examples of what stakeholder and product goals could look like.