Gilb’s Mythodology 12: Rational Dynamic Value Prioritization for Agile Projects

We think that current agile methods for prioritization can be improved.

Let us save you the time to read this paper. Here is the message:

You need to prioritize each sprint so as to maximize the set of measurable values delivered to stakeholders

What does conventional agile preach and practice today?

Product Owner [1] prioritizes ‘programming functionality’ (use cases, user stories, feature list) on behalf of users and customers.

Problems with today’s methods

1. Not based on a clear and rich stakeholder concept.
2. Not based on a quantified concept of stakeholder values.
3. Not based on conditions of priority (when, where, if, minimum, etc.).
4. Not based on changes to external conditions during development (like budget cut, quality requirements change, new deadlines).
5. Not based on a clear logical policy of priority.

Our principles of rational prioritization (© Gilb.com 2014)

Here are the basic ideas we believe need to be adopted by management regarding priority:

1. Measurable value maximization is the main idea.
2. Cumulative value delivery, towards long-term value goals, is desirable.
3. Values are based on the subjective opinions of critical stakeholders.
4. All stakeholder values can be articulated as defined numeric ideas.
5. The chosen set of values at any given level of perspective (e.g. CTO), should contribute to a defined higher level of perspective values (e.g. CEO)
6. The decision to prioritize an activity should be based on our estimated risk-adjusted contribution to delivering quantified stakeholder values.
7. The actual measured delivery of these values to the system or the final stakeholders will be done at each sprint.
8. The differential between estimated and real value delivery will be used as the basis for learning, and change, in decision making.
9. There are two levels of real value: value measured according to planned value metrics, and real value as perceived by current and future stakeholders, which may be different.
10. The ‘winner’ is the team that learns to really deliver to the really critical stakeholders the value they really need: no matter what the initial plans were.

Example of application of these ideas

Image may be NSFW.
Clik here to view.

Here is an example from a client of ours, Confirmit in Oslo [4]. They are using our value-based agile method, ‘Evo’.

In this snapshot of the 9th week sprint for the agile team of 4 people:

1. Goals: they have accepted the challenge to get to the 6 numeric goals in 12 one-week sprints. This is their main, long-term priority.
2. Constraints: they have as a first short-term priority accepted the challenge to reach the tolerable levels of the values.
3. The exact defined ‘scale of measure’ and corresponding test process for each of these value dimensions is not in this diagram, but is defined elsewhere [4]. This scale definition determines their real world priorities.
4. The development team (Evo team) is at liberty to choose to work on (‘prioritize’) any one or more of the six numeric values being worked towards during this Evo cycle (or sprint, if you must).
5. They have based their prioritization decision on the real measured feedback from previous value delivery cycles, shown in the column called Improvements %.
6. They chose to work on (prioritize) the value ‘Usability.Productivity’ because no progress at all had been made there during the previous 8 delivery cycles (of 12 cycles before release to market). It was still at the old system state of 65 minutes (to set up a market research report) and they need to reach a 25-minute goal.
7. The team then had a 30-minute stand-up design meeting, where they all contributed their ideas on how to save the 40 minutes (65-25 = 40). They are empowered to design in order to reach the numeric target (to prioritize a particular, promising, design). They call this “empowered creativity”.
8. During this particular real design session, about 12 ideas were suggested. For each idea, an estimated impact (in this case time saving) was made (a prioritization basis).
9. The design idea which had the best estimate (BY, 15) of 20 minutes, tagged ‘Recoding’ was accepted by the team (‘prioritized’) as the one they were going to implement as a team.
10. At the end of their 4-day delivery cycle, they tested (measured the level delivered) which was a 38-minute improvement, 95% of their goal.
11. One person on the team fine-tuned the design during the coming weekend, at the end of week 9, before they started on week 10. Actually measurably reaching at least 100% of the goal was considered good management.
12. So they achieved 12.5% (5 minutes) more than needed, and this requirement has no more ‘priority’ (claim on development resources) for cycles 10, 11, or 12.
13. You should be able to guess, analyzing Improvements %, what the team has to prioritize next.
    If not, the spreadsheet is programmed to give you priority signals:
    Red: You have not even reached the tolerable level.
    Yellow: You have reached tolerable level, but not yet the goal level.
    Green: You have reached the goal. No more priority for this fellow.
14. Experience shows that most teams, most of the time, manage to reach at least, or very near, 100% of the set of goals they are working on. In this case there were 4 parallel, small 4-person teams working on 25 value requirements.
15. The value requirements are set (prioritized) for the product by the marketing director and a corporate team.
    The reason the teams are so good at reaching their goals we suppose are:

• a. They choose which value to work on.
• b. They choose the technical design to use in order to get there.
• c. They learn from constant early feedback what works and what does not.
• d. They make their own estimates of how much they can achieve in their delivery cycle of 4 days.
• e. They can dynamically prioritize depending on the real-time numeric feedback set.

In other words, prioritization is delegated to the competent and learning level of technologist. This is a real self-managing team!

If this seems a bit much at first reading, try it again slowly. It is simple. Let me summarize:
“Do the highest value thing you can until you reach your goal levels. When all goals have been reached ‒ done.” [5]

Expected results of Rational Dynamic Value Prioritization

1. Better ability to meet a concurrent set of requirements fully by deadlines.
2. Better ability to quickly redistribute human resources to the weakest link (farthest from the goal level).
3. Better ability to learn quickly about value progress from real numeric feedback.
4. Better ability to maximize total value delivered at any point in time.
5. Remarkable ability to deliver quality and performance results of a very competitive nature.

These are not guesses or hopes, but are fully borne out by our clients such as Confirmit and, on a much larger scale, Citigroup, Intel, and HP (case studies at gilb.com).

So, are you and your organization ready to go for the real agile ideals of delivery of value to stakeholders? Or do you want to continue increasing the velocity of coding, even though you cannot define or measure the value produced?

References

1. Advanced Product Owners, Gilb’s Mythodology Agilerecord.com Feb. 2014 – http://www.gilb.com//dl799
2. ‘Beyond Moscow, Prioritization Techniques for Agile Teams’, by Tarang Baxi and Chirang Doshi, Thoughtworks 2013, 33 slides. This is an overview of a varietyof techniques from different sources.
   http://www.slideshare.net/tarangbaxi/prioritization-techniques-for-agile-teams. Chirag@Thoughtworks.com, and tarang@thoughtworks.com
   None of these techniques is in the vicinity of the methods this paper is discussing. As usual there is no concept of quantified stakeholder value requirements at the base of the thinking.
   A great many more papers/slides will be found by Googling ‘agile prioritization’. But they do not treat quantified residual dynamic value delivery as we do in this paper.
3. Gilb and Maier: ‘Managing Priority’ paper – http://www.gilb.com/dl60
   This is a deep and detailed exposition of the ideas of this paper.
   See also ‘Choice and Priority’ paper, http://www.gilb.com/dl48
4. Confirmit Case. http://www.gilb.com/tiki-download_file.php?fileId=32, From Waterfall to Evolutionary Development (Evo): How we rapidly created faster, more user-friendly, and more productive software products for a competitive multi-national market by Trond Johansen and Tom Gilb and www.gilb.com/dl50, WHAT’S WRONG WITH AGILE METHODS? SOME PRINCIPLES AND VALUES TO ENCOURAGE QUANTIFICATION’ with Confirmit Case.
5. “Done should mean value delivered to stakeholders”. Gilb’s Mythodology, October 2011. http://www.gilb.com/tiki-download_file.php?fileId=484