Tools & Artifacts
Velocity
Nov 24th
Def: Velocity is the amount of product backlog that a team can fully implement through product owner acceptance with in a given sprint.
The amount of product backlog in the definition above is often expressed in terms of “story points” or “ideal days”. Fully Implement implies that the product increment built during the sprint is accepted by Product Owner and is potentially shippable or at-least meets the definition of done. Also, velocity measurements are made only at the end of every sprint.
.
Track Record
The purpose of taking velocity measurements is to capture team-system’s track record at translating product backlog items into acceptable working software. This track record is typically expressed in total number of story points (velocity). Traditionally projects have been estimated prior to the start of the project. Estimates at their best are educated guesses. Guesses – none the less, based on assumptions that need validation from reality. In traditional project management this aspect of validating assumptions, made during the start of the project, is severely lacking during project execution. Project management is then reduced to protecting the planned estimates as opposed to achieving desired goals. Iterative delivery of software every sprint and taking velocity measurements for every sprint has negated the need to make large inaccurate estimates for the entire project. Instead small inaccurate estimates are made for each sprint. And that is a good thing! velocity works with the fact that estimates are inherently inaccurate (cone of uncertainty).
.
Velocity acts as a correction factor.
This is how: Say a team estimates (makes an educated guess) that they can fully implement 40 story points of work in a sprint. At the end of the sprint if only 20 story points are fully implemented and accepted then the team’s velocity for that sprint is 20. Velocity is informed by reality. Going forward, in the next sprint, if the team is consistent with their estimating technique then they can reasonably expect to complete about 20 points of work. Disciplined velocity measurement provides correctional ability to re-estimate amount of work that can be reasonably expected to be done in the next sprint. Thus allowing for reliable commitments for a given sprint.
.
Velocity and commitment.
It is important to note that velocity does not imply commitment. Most of us understand this however we behave at odds with our understanding. Too often I have observed product owners and other managers demand that a team commit to 20 points of work this sprint since their velocity previous sprint or average velocity was 20 points. Velocity is a tool to make reliable commitments, not a substitute for team judgement at making these commitments. Velocity does not imply commitment for the upcoming sprint and it definitely does not imply commitment over the next bunch of sprints.
.
Peering into the future:
Future can not be predicted. However one can arguably say that project release date based on velocity measurements is many times more probable to be true than the probability of releasing on a date arrived from purely educational guess work. I’m not aware of a scientific study that will prove my assertion but I’m confident that the probability of my assertion being true is greater than it being wrong 
.
Velocity directly depends on:
Reliable velocity measurement are based on consistent sprint length, same team members, similar product domain, similar product technology and consistent relative estimating. These are the direct cause and effect links with velocity. Changes to any of these factors make velocity unreliable. There are numerous other indirect factors which affect velocity. Understanding these requires understanding the relation between velocity and team.
.
Velocity and team:
The most common misconception is that velocity is an attribute of a team. This is understandable since changes to team members directly impacts velocity. This link of cause and effect is frequently yanked where in team members are changed thus impacting velocity thus re-enforcing our belief that velocity is an attribute of team. When in-fact velocity is an attribute of the system which includes both the team and the organizational environment surrounding the team. An example of organizational environment impacting velocity is evident through the dramatic increase in velocity observed in teams after they are collocated. There are various other organizational factors that affect velocity of a team system. Organizational culture and management’s response to team impediments are the biggest contributors to velocity improvements.
.
Velocity and team productivity:
Velocity is often mis-used to express team productivity. There are two common ways of mis-using velocity to express productivity
- MisUse 1. Velocity used to comparatively express productivity of one team over that of another team. This is when Team A is deemed more productive than Team B since Team A velocity in story points is greater than that of Team B.
- MisUse 2. Velocity from previous sprints is used to express relative gains in productivity. In other words if teams velocity in sprint 1 was 10 and then in sprint 4 it is 20 then it is incorrect to state that team doubled its productivity in Sprint 4. Let me share an example of a real team. This team had a consistent velocity in the range of 70-80 story points. In one of their sprints the team created an automation script that effectively made testing data inconsistencies a breeze. Stories that were initially estimated at 8 were now being estimated at 2. The level of effort involved with these stories decreased dramatically and so did their relative estimates. Their total velocity however remained at 70-80 story points. Now you will agree with me that the automation script did improve team productivity however it didnot change overall velocity. This is one example of why velocity is a bad measure of productivity. For an excellent article on productivity; see Martin Fowler’s article here.
What is Definition of Done (DoD)?
Jul 8th
DoD is a collection of valuable deliverables required to produce software.
Deliverable that add verifiable/demonstrable addition of value to the product are part of the definition of done. Such as writing code, coding comments, unit testing, integration testing, release notes, design documents etc. Definition of done helps frame our thinking to identify deliverable that a team has to complete in order to build software. Focusing on value added steps allows the team to eliminate wasteful activities that complicate software development efforts. It is a simple list of valuable deliverable.
DoD is the primary reporting mechanism for team members.
My favorite agile manifesto value is “Individuals and interactions over processes and tools”. Would it not be effective reporting to say, “Feature’s done”? DoD is a simple artifact that adds clarity to “Feature’s done” statement. A feature or Product Backlog Item is either done or it is not-done. Using DoD as a reference for this conversation a team member can effectively update other team members and product owner. Kindly note that by primary reporting mechanism I do not intend that DoD is the only reporting mechanism used.
DoD is informed by reality.
Scrum framework sets a very high bar of delivering “Potentially Shippable Software” at the end of every sprint. To me, potentially shippable software is a feature(s) waiting on product owner’s discretion to be released to end-users. Teams that are able to release to end-users within a maximum of 2 days can be reasonably said to have their product in potentially shippable state. For such teams: Potentially Shippable = Definition of Done.
For other teams working to achieve potentially shippable state, their DoD contains only a subset of deliverable necessary to release to end users. Such teams have DoD at various levels:
§ Definition of Done for a Feature (Story or Product Backlog Item)
§ Definition of Done for a Sprint (Collection of features developed within a sprint)
§ Definition of Done for a Release (Potentially shippable state)
There are various factors which influence whether a given activity belongs in DoD for a feature or for a sprint or for a release.
The most important is for the team to realistically answer:
Can we do this activity for each feature? If not, then
Can we do this activity for each sprint? If not, then
We have to do this activity for our release!
For activities that cannot be included for a sprint/feature: “Discuss all of the obstacles which stop them from delivering this each iteration/sprint” - (Building a Definition of Done)
Some of the common root causes for impediments that I have observed:
a. Team does not have the skill set to incorporate activities into the definition of done for a sprint or for a feature.
b. Team does not have the right set of tools. (Example: continuous integration environment, automated build, servers etc.)
c. Team members are executing their sprint in mini-waterfalls. Aha! Opportunity to be more cross-functional. Sharing of responsibilities across functional silos.
DoD is not static
DoD changes over time. Organization support and team’s ability, to remove impediments, enables inclusion of activities into DoD for feature/sprint.
DoD is an auditable checklist.
Task break down for a feature/story happens during sprint planning and also within a sprint. DoD is used to validate whether all major tasks are accounted (hours remaining) for. Also, after a feature or after a sprint, is done, DoD is used as a checklist to verify whether all necessary value added activities were completed. It is important to note that the generic nature of the definition of done has some limitations. Not all value added activities will be applicable to each feature since the definition of done is intended to be a comprehensive checklist. The team has to consciously decide about applicability of value added activities for each feature. For example following user experience guidelines for a feature that provides integration point (eg: web service) to another system is not applicable to that particular feature, however for other features within the system that interface with a human being require user experience guidelines to be followed.
Summary:
Definition of done is orthogonal to user acceptance criteria (functional acceptance) for a feature. It is a comprehensive collection of necessary value added deliverables that assert the quality of a feature and not the functionality of that feature. Definition of done is informed by reality where it captures activities that can be realistically committed by the team to be completed at each level (feature, sprint, release).
