Wednesday, July 24, 2013

5 Ways to Improve Agile Team Velocity

Relay Race Team practice to improve performance
An agile team's velocity is based on how the team sizes stories and how many stories and story points they commit to each sprint. Agile's self organizing principals empower teams to make these decisions in exchange for their commitment to complete the stories and having "shippable code" at the end of every sprint.

But what happens when management needs the team to accelerate its delivery? What happens if there is a significant opportunity or critical deadline and management wants the team to take on more stories or story points in a sprint?

Here are a number of ways management can either help, or influence its teams when this is needed:

  • Leverage Retrospectives - Retrospectives are part of most agile practices and give teams time to reflect on what worked well and what can be improved in the development practices or processes. I'd recommend management ask the team to consider a higher velocity as a discussion point during the retrospective. I'd also make it clear that the team should recommend steps that is under their control so that the exercise doesn't dissolve to a list of out-of-team improvements.

  • Increase Planning - I tell teams that they should target to have a backlog of two sprints of full defined stories, and an additional four sprints of story stubs estimated. If the product owner feels strong about the prioritization and definition of the backlog, it may help teams to dedicate blocks of time to get ahead of planning and target as much as four sprints of defined stories and an additional eight estimated. The added visibility gives teams the "big picture", helps them see dependencies, and gives them more time to find easier solutions.

  • Analyze Causes of Rework - All agile practices have a certain amount of rework in the form of changed requirements, poorly defined requirements, technical debt, defects, performance considerations and other sources. Teams should consider labeling stories (or tasks) based on the source of the rework, then consider measures that might reduce this work.

  • Learn the Customer - The Product Owner has got the tough job of aggregating many inputs from different user segments, sales teams, customer care feedback, research, and usage data. Development teams can play a role by insuring Product Owners have better data and more technical insight to make smarter decisions on what capabilities (stories) are required and what priority to fulfill the customer need. It can also lead to better technical design. So for example, if a feature is required by top customers but is not heavily used, perhaps the performance criteria can be relaxed and lead to an easier to implement design. 

  • Implement Smarter Solutions - Are teams leveraging existing code? Should a capability be developed as a service because it will have short term reuse, or should other capabilities take on deliberate technical debt? Are features too big, and will breaking them down, labeling them, and discussing with the Product Owner lead to lowering the priority on some of them? Are estimates challenged to help find better, more efficient solutions? In my experience, these disciplines can be overlooked by teams yet they can lead to better more efficient solutions.

You might argue that some of these steps don't directly improve velocity but are in fact measures to consider multiple solutions or reduce scope. This is technically true, so if you take on some of these approaches you might not see a direct percent increase in team velocity, but you might see the team deliver more capabilities in the same time frame.


4 comments:

  1. Biggest concern in many of my past experience is a weak link ( low performance) in the team that drags the team velocity down.

    ReplyDelete
    Replies
    1. Thanks for the feedback.

      Yes, if there is disfunction in the team, in the agile process, or in working with outside teams or stakeholders, then velocity will be subpar and failure may occur. Teams should raise these issues during stand-ups as blocks, or as part of retrospectives.

      Delete
  2. Hi Isaac. You make some great points.

    I think it's useful to draw a distinction between increasing the useful work that a team delivers in a sprint, and their velocity. Velocity only relates directly to the amount of work completed if estimation is consistent between sprints, and talk of "increasing the velocity" can make estimation less consistent.

    I've often witnessed developers inflating their estimates slightly when under pressure to increase the velocity. Some managers aren't wary of this trap and feel (when the velocity naturally goes up) that more work was completed, when in fact nothing has really changed.

    Rather than talking about "how do we increase velocity?", I prefer to use language like "how can we get more done?".

    Velocity may go up if a team starts working more effectively, but it should never be used as a measure of work done.

    Velocity's only purpose (as I use it, at least) is to help schedule a realistic amount of work in the next sprint, and to give some degree of realistic short-term forecasting regarding the work in the backlog.

    I think your closing sentence acknowledges this well:

    > if you take on some of these approaches you might not see a direct percent increase in team velocity, but you might see the team deliver more capabilities in the same time frame.

    Great post. Cheers…

    ReplyDelete

Share