Ask an Agile Coach: How do I handle the effect of carryover on velocity?

Our previous installment of Ask an Agile Coach had a new question in the comments:

As for the case when some of the user stories didn’t get completed, what happens to the user stories which were partially completed–say, 80% finished–but didn’t quite make it? How do you keep your velocity metric from getting hosed?

Practitioners have asked me variations of these questions many times over the years. I’ll paraphrase them into a single question:

How do I handle the effect of carryover on velocity?

When we gather data about something, there’s an innate temptation to filter the data to effect a desired outcome. It is often subtle; sometimes we don’t even realize we are doing it. This is a form of sampling bias, a term from the field of statistics. I love this sentence from the Wikipedia article on sampling bias:

A biased sample causes problems because any statistic computed from that sample has the potential to be consistently erroneous.

You handle carryover by letting it accurately affect velocity, whether that effect is positive or negative.

The purpose of tracking velocity is to provide feedback on how well a team can estimate, break down, and execute work within a fixed interval. Carryover implies a need to improve in one or more of these areas. When a team has a drop in velocity, be sure to talk about it in the retrospective. Are stories too big and bulky? Do tasks sit for days on the board waiting for the next handoff? It the team consistently over-committing during Sprint Planning, hoping for unrealistic throughput?

Allowing a skewed velocity sets a team up for disappointing its stakeholders. If velocity looks higher than reality (inflated velocity is far more common than deflated velocity), stakeholders are going to have expectations that cannot be met. Embrace the bad news, and use it to reinforce the message that our only hope is to get better at working together as people.

 

Barry Hawkins of All Things Computed provides coaching and mentoring in how to successfully apply the process and technical disciplines of Agile Software Development.

Ask an Agile Coach: What do I do with a sprint that ends with only incomplete stories?

Today’s Ask an Agile Coach submission comes from Jake Gordon via Twitter:

Anyone (@barryhawkins)  have any good articles on reaching the end of an iteration with only partially completed user stories? #agile

What do you do with a sprint that ends with only incomplete stories?

When a sprint ends and every story is incomplete, it is typically a symptom of one or more of the following underlying causes:

  • The stories were all larger than the team had estimated due to lack of cross-functional participation in the story writing and estimation process.
  • Team members kept switching between stories instead of focusing on single ones, completing them, then moving on to the next in priority. Minimize work in process (WIP).
  • Core parts of the process are being left out, such as a highly-visible task board, a burndown chart, effective daily stand-up meetings, etc.; as a result, feedback and handoffs are unnecessarily delayed.
  • The team is working on a platform or problem domain that is new, and its estimations are commensurately less accurate, leading to over-commitment.

When a sprint like this happens, effective retrospectives are essential. Ensure that all parts of the process have transparency. Visibility into how work flows from concept to customer is necessary for inspection. Use the insights gained from inspection to guide an incremental, sustainable rate of adaptation. Strive to eliminate waste and improve communication.

A single sprint where nothing gets completed is a warning sign that should not be ignored. Multiple sprints where nothing gets completed calls for a full-blown intervention. If you can’t get out of that rut on your own, seek external assistance.

 

Barry Hawkins of All Things Computed provides coaching and mentoring in how to successfully apply the process and technical disciplines of Agile Software Development.

Ask an Agile Coach

I never have a shortage of people with questions about applying Agile in the myriad possible scenarios of software development for business. This ongoing series focuses on answers to those questions.

If you would like your question to be anonymous, please let me know when submitting. I’d recommend email or a Twitter DM since you kind of let everyone know it’s your question if you use the other methods of contact. :-)

Have a question? Submit it via Twitter, LinkedInFacebook, or email to blog at barryhawkins dot com. I look forward to answering them here!