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

Definition of Done: How to Ensure Compliance

Near the end of the Scrum Guide, there’s a section on the Definition of “Done”:

When the Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. Although this varies significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the “Definition of Done” for the Scrum Team and is used to assess when work is complete on the product Increment.

Who is everyone? Everyone includes the Product Owner, Development Team, and Scrum Master although key customers, sales, product management, product support, and managers should also be aware of what the team understands 'Done' to mean.

 

The Scrum Master ensures that a definition of done exists for the scrum team.

How to Define 'Done' for Your Scrum Team

Chris Sterling of Sterling Barton, (www.gettingagile.com), has written an excellent paper on "Building a Definition of Done". Chris Sterling has identified a four step process toward getting a definition of done. These are:

1. Brainstorm – write down, one artifact per post-it note, all artifacts essential for delivering on a feature [user story], iteration/sprint, and release
2. Identify Non-Iteration/Sprint Artifacts – identify artifacts which cannot currently be done every iteration/sprint
3. Capture Impediments – reflect on each artifact not currently done every iteration/sprint and identify the obstacle to its inclusion in an iteration/sprint deliverable
4. Commitment – get a consensus on the Definition of Done; those items which are able to be done for a feature [user story] and iteration/sprint

Let’s assume you have your definition of ‘Done’ documented in a team charter or some other means and have it properly displayed on your scrum board for all to see.

 

Now What?

 

Complying With The Definition of 'Done'

 

In the sprint planning meeting, the Scrum Master should get the Scrum Team to re-confirm their commitment to the team’s definition of ‘Done’. This ensures that everyone on the Scrum Team, which may include new people to the team, is aware and understands what ‘Done’ means. It’s possible that the definition of ‘Done’ had changed during the last sprint’s Retrospective, maybe to tighten up on the quality goals. The Scrum Master goes through the definition of ‘Done’ with the Scrum Team and everyone re-affirms their commitment to it.

 

During the sprint, everyone on the Scrum Team is responsible to follow and adhere to the definition of ‘Done’. It is the Scrum Master’s responsibility to ensure the other members of the Scrum Team (Developers and Product Owner) have been coached and trained to do this. If the Development Team and/or Product Owner are not following the definition of ‘Done’, we hold the Scrum Master accountable.

 

What should happen if the Scrum Team cannot follow one of their definitions of ‘Done’ to the letter? Let’s assume for the moment that a Scrum Team has the following definition of ‘Done’ for a user story:

• Acceptance tests written covering all acceptance criteria.
• Acceptance tests and regression tests run and pass.
• Acceptance tests results reviewed by the Product Owner.
• No known introduced bugs.
• Product demo’ed with Product Owner.
• Product documentation, technical and user, updated.

The Scrum Team works hard following the definition of ‘Done’ and is successful except that they’ve introduced some new bugs, violating the ‘no introduced bugs’ clause of the definition and the sprint ends today. What should happen? This is where the Scrum Master might need to hold back the torrent of people, (managers, sales, product management), all of whom want those stories now! Strictly speaking, the user story or stories that introduced the new bugs cannot be considered ‘Done’ and the story(s) are not demo’ed in the sprint review. However, during the sprint review when discussing what didn’t get ‘Done’, the offending user story bugs might be discussed and stakeholders and Scrum Team alike may determine that the bugs are of little importance to the end-users. (Why this didn’t happen before the end of the sprint is another matter that the Scrum Team would analyse in the Retrospective.) The user story would be added to the next sprint to be integrated into the ‘Release’ branch, probably re-tested, and the insignificant bugs closed as ‘not a problem’. It’s most likely that the Product Owner will have the user story ‘Done’ within 24 hours of the sprint review and can then release it at their leisure. If the bug is significant but the stakeholders and Scrum Team determine that the bug is of little importance to the end-users now, the bug could become a new user story to be addressed later. (You'll note that this second scenario is actually adding to technical debt.)

 

The whole point here is that the definition of ‘Done’ should stand uncompromised throughout the sprint. If there’s a problem with the definition of ‘Done’ that came out during the sprint, it should be addressed during the sprint Retrospective and any changes to the definition made and agreed to there. However, the Scrum Team should heed the words in the Scrum Guide which say, “As Scrum Teams mature, it is expected that their Definition of ‘Done’ will expand to include more stringent criteria for higher quality”. This means that the definition of 'Done' should be strengthen rather than weaken as time and sprints go by.

Tweet