Anti-pattern: Assigning Story Points During Backlog Grooming

Story pointing during backlog grooming is well-intended but can be a waste of the Product Owner’s (PO) time.  Points are a tool for the development team to figure out what they can take on, and generally are assessed during Sprint Planning, not before.  A PO may have opinions and insights when a particular story’s points appear out of proportion, and can support Sprint Planning, but POs should defend precious Backlog Grooming time by not allowing story pointing to intrude.

One common approach for backlog grooming is “three amigos”, in which the Product Owner, Tech Lead, and Test Lead (at a minimum) form the core backlog grooming group.  The order of items to be discussed is maintained in advance, and people whose input would be critical may be invited as needed, with sufficient advance notice.  That approach addresses concerns about over-populating the grooming sessions.  Some teams put rosters together with a condensed attendance to supplement large-scale backlog grooming meetings, and to efficiently refine the outcomes of those large meetings.  Those leaned-down rosters may be the best quorum for all backlog grooming sessions.

A compact group of people can be best for initial grooming, but not the best group for estimating and refining stories.  Under Scrum and SAFe, the Increment Planning/Sprint Planning session involves the Product Owners, Scrum Master, and all development team members.  Questions and clarifications about the stories are discussed, their relative complexity evaluated, and then they receive pointing.  (Remember that pointing is a metaphor for complexity, not directly for hours.) 

Points as a “thing” can be insidious. Teams deliver systems, not points.

Once points are assessed, the development team discussed how many of those points they think they can commit to for the upcoming iteration.  The points completed for the last iteration (velocity) informs them about that, but they consider various factors – technical debt, interruptions, people’s absences, etc.  This human element makes planning slightly messy, and prevents Velocity from being a mathematically precise predictor.  And that’s ok.  Pretty close in truth is better than delusions of precision. 

Under agile philosophy, this collective estimating provides many benefits.Not only does it help all team members learn how to contribute to estimating, it improves the estimates themselves.Estimating as a group ensures that complications and snags are brought out into the open or not forgotten.It ensures they are discussed from the viewpoint of the entire team’s capability, and not estimated as if Super #1 Star Programmer will be doing all the work.

Pressure to Point Prematurely

Not only have we seen story pointing taking place during grooming, we have noticed that story pointing itself needs to be corrected.  We have observed teams in which the same three people (out of a team of 20 or more) always provide story pointing input.  Story pointing requires the input of the entire development team, not just a few.  Having two or three people out of 15 - 20 doing all the pointing may seem efficient, but generally indicates one of several situations:

·         The team is disciplined enough to not take initial estimates too seriously. These teams view the “Three Amigos” pointing as efforts to understand the work’s complexity. For every story, these teams will refine the points as a group. This requires force of will to resist the temptation to go along with the initial number. As much as developers may criticize clients for treating estimates as hard facts, they can be just as guilty of it!

·         They just haven't learned how — or why —- to point as a team (this is a very common reason.)

·         Teams are behind the curve and are trying to make up lost time by not doing "planning poker" and other pointing exercises.  That is false economy, as it is unlikely for a team under pressure to have its work estimated well by just a few representatives.  Time saved by not pointing will may be lost in struggling to meet Sprint commitments.

·         The agile management tool is being manipulated to ensure that points and hours estimates are always clean.

·         Leads in “hero mode” don’t want to relinquish control over pointing.  Unfortunately, this collective approach to estimating is hard for some people to accept, particularly who have spent years estimating on the behalf of large groups of other people.  And sometimes those people (such as lead developers) are who are in the small backlog grooming group.  They need encouragement to not fall back on premature pointing. 

·         The only people doing meaningful work on the team are the 3 or 4 that show up at backlog grooming; the rest may not be effectively used or are incapable.  This results in skill stagnation, whereas the customer would benefit from skill growth.  Granted, a project may kick off with only 2 out of 20 developers being truly expert on the system, code language, data and functionality.  At the end of the year, however, there should be 20 people in the vendor work force with higher expertise; some of those developers may be candidates to work with whichever vendors wins the contract for the phase.  It does not benefit the sponsors for a year to go by with the same few high-end experts doling out work to a raft of medium performers, and not expanding the worker base qualified to lead development on the system.

·         There is a high-performing development team that operates so smoothly, with parametric estimating, that a couple of people can point for the entire team; only minor adjustments are needed.  I haven't seen that level of sophistication more than a few times in 30 years, and it's only a flu bug away from being completely disrupted, and it's a resignation away from disappearing.

Story Pointing is an example of the act of planning bing more valuable than the plan itself.  Story Pointing serves to call out the complexities and aspects of the story, and makes everyone justify their position on the relative complexity of that story.  It's not about how long the story will take, it's about how complex the problem is.  The whole team needs to hear that.  Hours estimating is an outgrowth of story pointing, not the leading activity.

Preliminary Estimates

It is appropriate to assign preliminary estimates to stories during grooming, Such rough-order-of-magnitude estimates help sanity-check priorities and Release plans.  Rather than points, however, a less confusing practice is to use T-Shirt sizes. This lessens the temptation to just take the preliminary estimate and “run with it” during Iteration planning.

Use T-Shirt Size estimates as a sanity check during direct story pointing, but not as a strict constraint. There should be no T-Shirt Size-to-Story Point rubrics that will say what size equals how many points.  Such rubrics, especially when used too early in the organization’s maturity, lead to a false sense of precision.  False precision leads to flawed metrics programs, people struggling for power over the measurement program, pushing misleading data, and other detrimental behaviors.

Product Owners and other backlog grooming participants can, however, look at points assigned to stories to check whether their rough, relative T-Shirt Sizing correlates to the proportions of the finished work.   For example:

·         Suppose Feature A has a T-Shirt size of “Small.”  The stories created for that feature wind up taking five people 4500 keyboard hours to complete

·         Suppose Feature B has a T-Shirt size of “Extra Large.”  The stories implemented to create that feature wind up taking 2 people 80 hours keyboard hours to complete

In this example, the hours to complete seem disproportionate to the original T-Shirt sizing.  The people grooming the backlog would want to know that so they could discuss what factors they missed for Feature B when evaluating its rough magnitude.  The outcomes could help them do a better job of rough sizing in the future.

Refining a T-Shirt-to-Points Rubric would not help anyone, since the assumption during T-Shirt sizing is that some details are unknown at first.  The Rubric would always be unstable.  A list of common system attributes and risks, an assessment of interconnecting system, and an overview of the Architectural Runway are examples of data that would be vastly more useful than a Rubric would be.

Giving In to Points Pressure

Much pressure for this behavior comes from outside the team. We have heard managers tell teams, “you need to increase your points count so you can get more credit.” This goes back to wanting to treat story points as a “thing” much as credit hours in school are a thing. But, as my colleague Vickie Figuero commented recently, “This isn’t high school! You’re not collecting credits towards your diploma.”

We’ve also heard teams pressured under the rationale, “You need to point earlier so you can assign tasks further out.” Almost invariably, this comes from a member of the PMI community, anxious to get their Gantt Chart* fleshed out twelve months in advance, with 20 layers of breakout, before Sprint 0 is over. (I refuse to refer to a MS-Project file as a WBS. That’s for another post.) The points may be premature and half-baked, but it doesn’t matter, we’ll now have a plan! That’s not useful, either.

Story points have no empirical value.  None.  Zip.  A point is not equal to 20 lines of code, 1/15th of a microservice, a 30 column table, or any other measure of work product.  There is no Point Standard cast in gold and stored alongside the National Prototype Metre Bar in Paris. A point doesn’t firmly equate an hour’s worth of work either, although some groups use that as a “get started” rough equivalent. Points are an imprecise and malleable way of sizing stories relative to each other.   

There is no fixed duration or complexity for a given point value.

Just as story points do not have empirical value, neither does it directly matter how many points you deliver.  It doesn’t matter! What does matter is how much functioning product you deliver, how much refinement of the backlog you help with, how much refactoring and innovation you perform, how much infrastructure readiness and stability you deliver.  That’s what the Product Owner is buying, not points. We see many business sponsors finally backing away from asking for points delivery, even on contracts that mandate a fixed number of points. They are sick of all the effort and wrangling over such an imprecise indicator. 

Points are a team’s internal tool for guesstimating, tracking and reporting its own progress relative to a single sprint. Remember that next time you’re pressured to assign points in a session where the team isn’t present. There are limited circumstances in which groups external to the team have any reasonable concern about story points. They may include:

• When there is a radical (not incremental) number of points taken on in a sprint, or left out, compared to the previous one. (Emphasis on compared to the previous one, not compared to a sprint taking place a year ago, and never compared to some other team’s sprint).  Outside people may need to know what events cause radical fluctuations in points estimation. Sometimes they can help resolve the root cause faster than the development team can. Just a few causes of radical fluctuations include:

  • Research spikes, especially when several occur at the same time

  • Team attrition, vacations, illness. 

  • Large scale refactoring (which you should try to prevent like the plague)

  • Product Owner or Subject Matter Expert unavailability

  • Low responsiveness from external groups that keep critical volumes of work from progressing

  • Problems with the development or staging environments outside the team’s control

• When the relative number of Defect points compared to those for User Stories/Spike Stories changes radically.  This could indicate a quality problem that people outside the team naturally have an interest in.

• The relative number of points delivered and rate of burndown are perfectly steady and consistent.  Bean counters think they like this, but it probably indicates a problem.  Software teams are not factory lines, and I can tell you from my experience in manufacturing that the best production lines have variation.   When we see super-perfect velocity, we usually see Product Owners are dissatisfied with the quality and quantity of working software delivered.   This situation often comes from a Scrum Master being pressured to have perfect delivery for reasons other than supporting open and honest communication.  

Summary

Story points have no real relevance outside of the development team.  Trying to point too far in advance misses the idea of why points are used in the first place.  Instead of mutating points into productivity, budgeting, and other macro information, the organization should seek out different, better indicators.