There is a big debate out there about the value of estimation on Agile projects. There are two items that need to be distinct when we talk about this. The first is estimation as a Team Learning activity. the second is estimation as part of the basis for planning.
Let’s look at team learning first:
Estimating as a Team Learning Activity
The primary value of estimating (as a group) is in the team learning. The estimate “deliverable” is secondary. Repeat: The primary value of estimating (as a group) is in the team learning. The estimate “deliverable” is secondary.
Planning poker in particular provides a structure for making sense of the estimating task and the learning that comes from that. When teams estimate with planning poker, they are learning about the work, and EACH OTHER.
Not Understanding Requirements Creates Anxiety
Agile processes are patterns and practices that increase sense-making at the level of group. When we do not know “what a requirement means”, we worry about it. When we know what something means, like a requirement, that reduces anxiety by increasing the perceived sense of control. A sense of control makes us feel good. We know what it means. That reduces worry about what to do next.
All Learning is Change, All Change Creates Anxiety. Therefore: Learning Creates Anxiety.
All learning is change. Change is stressful because the process of change reduces the “known” and/or increases the “unknown”. The ratio of “unknown items” to “known items” goes up when the process of learning is taking place. The initial process of learning creates a progression from the known to the unknown.
Knowing where you are is very comforting. Not knowing is stressful. Learning is de-stabilizing and causes stress. Learning causes you to shift from the known towards the unknown as you engage in the learning process. The process of learning creates substantial instability…until your new learning is fully integrated.
Lack of Structure Creates Anxiety
As if the process of team learning was not already problem enough, we also have the structure problem. This is a social problem. People feel stress when structure is lacking. We also tend to feel a sense of control when we are participating in well-structured social activities.
Ritual Creates Safe Space for Learning: Planning Poker As Ritual
Now let’s discuss estimating using planning poker. As stated previously, the primary output from the activity is learning, not the estimate itself. The act of estimating using planning poker is a ritual activity whose goal is manage the sense-making, and the subsequent integration of the know-how.
Planning poker is a ritual. A ritual provides known A-B-C steps for beginning, experiencing and completing a journey through the learning. A planning poker session that is facilitated can be viewed as a ritual of learning that manages the state of “not knowing”. The planning poker ritual provides structure and a predictable experience of dialogue and structured learning.
In summary: team learning creates instability. This ambiguous state of being is best managed with predictable rituals that help in getting from here to there.
With the discussion of team learning behind us, we can now talk about a very basic problem: using estimates for planning.
Almost All Estimates are Wrong
Estimates are usually wrong. Especially early in a project, not much at all is known. Any estimates are flawed. Pretending this is not true does not make the reality go away. What usually happens is, we take these flawed estimates, use them for projections of cost, features, delivery date, and quality. We then make commitments that are binding between the development team and the product owner and/or project sponsor. This is a serious error in many dimensions.
Almost All Rituals are Good
That said: we can argue that Agile methods manage the instability inherent in all team-learning. Planning poker, for example, is a well-understood ritual for generating team-learning as a primary side effect of producing an estimate. We can say that each Scrum meeting is a kind of team-learning ritual.
Are Scrum Ceremonies Actually Rituals That Help Manage the Instability of Learning?
Yes. Jeff Sutherland and Ken Schwaber refer to Scrum meetings as ‘ceremonies’ in the Scrum literature. This is very telling language.
Could it be that Scrum is actually implementing a repeatable series of rituals that are managing the in-between, destabilizing nature of team-learning?
What is Planning Poker Really?
Planning poker is a team-learning ritual that is focused on understanding software requirements. The planning poker ritual is predictable, repeatable, and structured. While maybe 3% of all agile teams are comfortable in total ambiguity, the other 97% need rituals to help them impose some structure on the process of generating (destabilizing) team learning.
We can argue that Scrum ceremonies like the Retrospective are also rituals that are managing states of uncertainty. They provide structure to help navigate the often ambiguous states of being that are created during team-learning.
What Can We Do?
We can do the following to advance the state of the art:
- Admit that group-estimating procedures like planning poker are actually rituals that are helping to provide structure during learning states;
- Admit that the true value of estimating is the generation of team-learning and not the estimate itself;
- Admit that estimations are tremendously under-rated precisely because estimates (even when incorrect) serve reduce the “sense of ambiguity” that comes from not knowing the ultimate cost of a project;
- Design useful, customized and tailored agile-learning rituals , beyond planning poker, which manage the ambiguous nature of team-learning.
The moral of the story? It ain’t as easy as it looks.
Related Links:
Sense-Making: http://en.wikipedia.org/wiki/Sensemaking