Increasing Velocity vs. Stable Velocity

The question often comes up whether a Development Team can reach a point where their sprint velocity becomes stable. I think that velocity may tend to stabilize but it won't be stable until the Develop Team executes its sprint perfectly and nothing new exists for the team to experiment with. Here are some ideas that I believe can help the Scrum Team achieve a stable velocity.

If the Development Team is doing:

• Product Backlog grooming (stories and acceptance criteria are understood and broken down to an appropriate size),
• Small User Stories (each story taking 1 or 2 days depending on how many people work on it),
• Defining acceptance tests before the start of the sprint (understand the acceptance criteria, the scope of testing, and the most probable approach to testing),
• No "unplanned" work in the sprint (e.g. Support calls),
• No unnecessary "manual" work (identify and analyze manual work to see if it's cost effective to automate),
• Pair Programming and/or following a Coding Standard for code review,
• Test Driven Development (TDD),
• Acceptance Test Driven Development (ATDD),
• Continuous integration (new/modified tested code is integrated daily for automatic component/functional/system/regression testing),
• Code Refactoring (to improve the code quality and the overall design),
• Automated Unit Tests,
• Automated Integration/Component Tests,
• Automated Functional Tests,
• Automated User Story Acceptance Tests,
• Automatic Regression Tests (Team is probably not doing good regression testing unless these are automated).

And the Development Team is:

• Cross-functional (has the necessary expertise among its members to take a user story from its initial concept to a fully deployed and tested piece of software within one sprint),
• Working "normal" work hours (Development Team is working at a "sustainable" pace),
• Happy as individuals and as a team (no one "dreads" coming to work),
• Not interrupted or distracted by anyone or anything outside the team (Scrum Master stand guard if necessary),
• Identifying impediments to the Scrum Master quickly (hopefully before there's any impact),
• Not distracted by email (turn off the mail server),
• Not distracted by the phone (have a phone available to the team in a separate room),
• Not adding to its Technical Debt during sprints (adopt a zero introduced defects as part of the definition of done),
• A cohesive entity (has a shared view on the development objectives, the design ideas in the code and what makes for good code),
• Self-organizing (always on the lookout for ways to improve).

And the Scrum Master and Product Owner are:

• Shielding the Development Team from "unplanned" work,
• Shielding the Development Team from outside distractions,
• Removing the Development Team's impediments in a timely manner,

If all the items above are being done then I would say that the Team's velocity will probably be fairly stable.

However, the Scrum Master is responsible for helping the Development Team to improve even when it appears that the Team is doing everything as efficiently as it can. From the Scrum Guide: “The Scrum Master encourages the Scrum Team to improve, within the Scrum process framework, its development process and practices to make it more effective and enjoyable for the next Sprint.” The point being that trying to improve the team's velocity should be the norm – not standing still. To achieve improvements, the Scrum Master should ask the question:  Is the Scrum Team trying new things every sprint to help improve themselves? The Scrum Team should be able to identify how it can improve its velocity by working smarter, not harder.

Tweet