Stories and points aren't real, focus on the goal

I remember the first time driving overseas. As much as everything was more-or-less the same, it was different, notably in highway etiquette.

For example, where I was at, drivers kept to the rightmost lane as if there were a magnet on the right-hand side of the highway always pulling them back as soon as possible (versus the “occupy the middle lane” approach often seen here in Canada). Passing would happen at the last minute as a driver approached a slower moving vehicle like it was a dance around them. You would almost never see a vehicle moving out of a closing lane a kilometer in advance of its end like you often see here. Maneuvers that would be considered aggressive and earn a honk in North America were more routine non-offensive occurrences. And the honks that routinely did happen, were meant to be forgotten a second later.

One underpinning difference was the driver’s relationship with the lane. From my perspective, North Americans are more likely to feel like we own our space in the lane like property. Other regions see lanes as paint on the ground suggesting a path to steer their vehicle. This was a bit eye-opening as it made me realize that at the end of the day, lanes don’t actually exist, they’re just a shared abstraction — it’s just pavement. Granted, it is an important conceptualization (especially if you are occupying that centre lane and someone is passing you on both the left and right); however, conflating lanes with a naturally occurring universal phenomenon would be incorrect. Shopping carts in a supermarket don’t need explicitly marked lanes, which is not all that different than how rush hour traffic in a more historic city whose roads predate cars by hundreds or thousands of years also manages without the same well-defined lanes that you’d find in North America.

Sprints, stories and story points in scrum — or any project management construct for that matter — are a similar common abstraction. They all serve an important purpose, but they don’t technically exist. Developers and customers are real; working software is real; the money that pays the invoice for the delivery of a product is real. But the sprint, its story points, and even the stories themselves aren’t real, they’re only a means to an end. They’re the lanes that create a common understanding of a complex domain for both development teams and customers. Such a conceptualization is critical for success, but a customer typically isn’t too concerned with how their product is split into stories or how many story points they’re assigned.

With that in mind, my thesis isn’t that there’s anything wrong with any of these artifacts — indeed, they’re effective abstractions. My point is that it’s important that real is always given a higher priority than the abstract. We see this in our driving analogy too: a driver in a large city such as Toronto will “adapt” the abstract (lanes, signalling procedures, etc.) to the real (that there are millions of people with places to go), but they wouldn’t abandon the rules altogether.

However, it does happen that the abstract is given equal or greater importance than the real in software projects. For example, I once knew of a team that would avoid addressing some support issues in one sprint because they didn’t want to distort their metrics. Tending to metrics so they’re meaningful and actionable is important; however, having these metrics dictate a response to a real-world situation is the abstract project management constructs taking precedence over the real work of engineering software — and curiously conflicts with the “responding to change over following a plan” pillar of the Agile manifesto.

The official Scrum Guide [1] is amenable to this point-of-view. Some of the concepts and philosophies that are commonly associated with Scrum in fact aren’t a part of the core methodology. The burn-down chart is only mentioned in one sentence as a tool to gauge health (with the caveat that, “they do not replace empiricism [making decisions based on what is observed]” [1, p. 9]). There is no mention of a “ticket commitment” whereby all tickets committed to at the beginning of the sprint need to be taken to completion by the sprint end (see [2] for a discussion on this). The word “velocity” doesn’t appear in the document.

Even if burn-down charts and velocities are helpful tools to measure, learn, and plan, it’s important to remember that the only critical component by which to gauge a sprint’s success is whether the sprint goal has been reached.

The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives. [1, p. 12]

Everything except that goal is a means to an end — a helpful abstraction to guide the process, but not an end in itself. Defining the methodology in this manner is an elegant way of ensuring that the real is given priority over the abstract.

Focusing on a goal instead of the process is a natural motivator for a team too. Knowing that everyone is working toward that goal (e.g., “A visitor can order a product” [3] or “An admin can set time conditional pricing for a product”) directs a team’s energy and gets everyone working collegially toward the same end. It also means that if technical complexities are found partway, or that the work would be better broken down in a different way, then there is not only the flexibility, but the expectation to make adjustments. In theory, meeting the sprint goal can technically justify the shape of any burn-down — although I would be curious to evaluate if a goal-oriented approach makes for healthier-looking burn-downs anyhow.

However, when the abstract means become the manner of team evaluation — for example, when teams are reminded of their ticket completion rate or story point velocities — there is the risk that the stated sprint goals become mere decoration to the process. The implicit motivating goal that the team will follow is, “complete as many tickets as possible.” The abstract tickets are tacitly given a higher priority than the real software: developers won’t have an incentive to think bigger picture than the tickets in front of them, developers will strategically select tickets based on what can be completed and recognized before the end of the sprint (which may not always reflect what is best for the product), and (arguably) team motivation will be more tepid as a goal around a product is often more exciting than a goal around an arbitrary project management metric.

Essentially, it’s how the score is kept that dictates the game you’re playing.

In practice this is a difficult balance to strike — there is a human element to this that can’t be reduced to process and procedures. In the driving analogy, even if you’re getting from place A to place B, there’s a huge gap between doing so while endangering the safety of others along the way, to worrying about signalling a lane change on an empty highway. Somewhere in the middle there is getting from point A to point B (the real) while reasonably balancing against the written rules and regional conventions and conditions (the abstract constructs). A balance here often requires knowledge of team members and their working habits, company conventions and culture, and of course the needs and expectations of the customers and clients for whom the software is being developed. Balancing all of this is an art; however, my recommendation would be to start with the goal and work up from there.

References