What do User Stories, Story Points, and Objective & Key-Results (OKR) have in common? The obvious answer that all three have something to do with Agile is too simple and doesn’t count. And no, I’m not doing cheap SEO here with these buzzwords in the first sentence of this article. Instead, it is about a common misunderstanding in applying these methods. This misunderstanding involves reducing the method to the respective artifact, although collaborative development is much more important than the results. The written user story, the estimated story points, or the finished OKRs are only manifestations of shared understanding. The journey is the destination.
The Promise of a Conversation
Alstair Cockburn described the user story as the promise of a conversation. That’s why Conversation is one of Ron Jeffries’ three Cs for good user stories. A user story was never intended to be a mini-specification, but intentionally had to cope with the limited space on an index card or sticky note (Card as another C by Ron). So the goal is not to have the user story written, but the journey of joint clarification of what might be meant and how best to implement that. The notes are then just the thought supports for the team.
The Value of an Estimation
One of the most popular methods for estimating user stories is Planning-Poker. Here, each team member is given a set of poker cards with the numbers for so-called story points, which are usually based on the Fibonacci sequence with its increasing spread of distances, for example, 0, 1, 2, 3, 5, 8, 13, 21, 34, often supplemented by a card for “no idea” and a card for “pause.” After the product owner presents the user story to be estimated, each team member chooses the number that best reflects the complexity of this story (this works better the more stories the team has already estimated and implemented, since these then can serve as a reference for this type of relative estimation). Then everyone reveals their cards at the same time. Most of the time, there are outliers in the estimates, either up or down, and it is essential to discuss the assumptions or fears behind them with the team. After this clarification phase, the estimation and, if necessary, the clarification is repeated. Typically, the numbers converge better with each iteration.
The purpose of planning poker (and related estimation methods) is not the actual number of story points but the conversation required to determine and agree on them. Estimating itself is only one possible structured process to lead the conversation called for by Ron Jeffries and Alstair Cockburn.
The Path to Objectives
The Objectives & Key Results method originated in the 1970s under Andy Grove at Intel. However, OKR came into vogue when John Doerr introduced this type of goal setting in 1999 at Google, where it is still used consistently today. OKRs (like their predecessor, “Management by Objectives”) help align an organization and its employees around common goals. In the case of OKRs, these goals are described by qualitative and ambitious objectives, each with key results representing qualitative indicators of progress toward the goal in question.
As with user stories and their estimates, OKRs risk being reduced to just this result, i.e., the most coherent and complete framework possible with objectives formulated according to the method. Much more decisive, however, is the process of jointly defining and developing the objectives and key results at all levels. It makes a massive difference whether objectives are communicated and cascaded in a traditional top-down manner or jointly developed and agreed upon in an interplay between top-down and bottom-up. In both cases, there will ultimately be a more or less coherent framework of goals at the various levels, but commitment and ownership will only exist with involvement. The journey is the destination. This is precisely why John Doerr’s original presentation at Google 1999 said that at least 60% of the objectives have to be bottom-up (from this workshop by Rick Klau):
What other examples of misunderstandings of this kind can you think of? Where else does fixation on the outcome lead to shortcutting the all-important process of collaboration?