Before the First Scrum: Velocity

Before an organisation goes Scrum, they're most likely to be following a waterfall paradigm and using Function Points, Lines of Code (LOC), Analogy, etc., for software estimation in hours per task. They'll probably also use Earned Value or Microsoft Project as a means to measure their progress and ultimately, their profitability. In Scrum, story points are generally used as the estimation mechanisms and Velocity is used to measure progress and, indirectly, profitability.

Velocity In Hours

If the Scrum development team chooses to use hours as their estimation mechanism then velocity is easily arrived at: (number of team members * effective hours/day) * number of days in sprint. Using hours has a certain appeal to teams unfamiliar with Scrum and story points but using hours implies a estimation precision that simply doesn't (and never did) exist. Another issue with using hours is the 'User Stories' can read more like the waterfall-ish requirements that preceded them and be of a technical nature. Although these may capture the basic functionality, they may fail to grasp the end users' point of view, give little or no hint of usability, and tend to read like development tasks; telling the development team how to implement the feature.

Unlike estimating in hours, story points are at best only an approximation of the effort required. The Scrum Master should steer the team toward using story points as soon as practical.

Velocity In Story Points

Prior to the first sprint, have the development team define a reference user story. A reference user story is one were the entire development team can reach an agreement on the effort involved in developing the feature, the complexity of developing it, and the risk inherent in it. This can be one of the user stories the product owner has written for the team or can be some small bit of previously implemented functionality that is familiar to the team. In either case, the reference story is usually something that can be completed by the whole team within a day or two. Once the reference user story is established, give this story 2 story points. All other user stories are estimated compared to this 2-point reference story. A story that is assigned a 4 should be twice as much as a 2-point reference user story. A story assigned 1 is one-half as much as the 2-point reference user story. The actual length of time eventually becomes unimportant. Planning Poker is probably the best estimation technique to use when estimating user stories.

All stories considered for the first sprint are estimated by comparison to the reference story. The team selects and estimates stories they believe can be completed to the satisfaction of the team's Definition of Done in the first sprint (see Definition of Done: How to Ensure Compliance). The total count of story points becomes the team's initial estimated velocity.

Velocity Is For The Scrum Team

Once the team has arrived at an estimated velocity, the Scrum Master can then begin using this as a KPI for the team. However, care should be taken to ensure that velocity is not used to compare between teams (see Velocity as a KPI in Scrum). The Scrum Master can track the team's velocity and over time, measure the team's performance (see  Increasing Velocity Vs Stable Velocity).

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