Calculating your Team’s Target Velocity

In an Agile world, using empirical data helps a team understand their pace (e.g., in regards to the Agile Principle of sustainable pace).  Sustainable pace is a concept that attempts to identify the reasonable amount of work a team member can complete while still being able to sustain that pace indefinitely while remaining engaged, innovative, and enthusiastic.  A key question is, how does a team know the amount of work they can do?

One way to do this is to capture a team's actual velocity.  A team's velocity is the amount of work a team can do in an iteration or sprint that meets a quality criteria such as Done Criteria.  The work is usually captured in several requirements or user stories each with an estimate or size in story points. The total story points of user stories completed in a sprint is an example of a team's velocity.  I'm using story points in this article as the example.  A story point is a scope measure which is equivalent to a unit of effort, complexity, and risk associated with the work.  The question is, how does a team determine their pace or target velocity (depending on the word you want to use) for the next sprint. 

There are several ways to approach this and using the empirical data from the previous sprint’s actual velocity is a good start.  It is up to you to determine what works best for your team and context:

• The simplest way to calculate the team’s target velocity (TTV) is take the previous sprint’s actual velocity and use this as the team’s target velocity.  An example if in the previous sprint, the team's actual velocity (TAV) is 120 story points, then for the next sprint, the TTV will be 120 story points.   
• Another simple way to calculate the team’s target velocity is take the average of the previous sprint’s actual velocity.  As an example, if the previous sprints’ TAVs were 80, 90, 110, 100, and 120 story points, then divide this by 5 and the TTV will be 100 story points. 
• A more complicated way is take the previous sprint’s actual velocity, plus credit points for completed effort of unfinished work, minus points that team members will be away on holiday, vacation, training (aka, out of office).  As an example, if the previous sprint’s TAV is 120 story points, then take credit for completed effort of unfinished work as 9 (3 points for 3 unfinished user stories), minus 10% of the previous sprint’s TAV due to the Thanksgiving holiday or 12 points, bringing the total to 117 story points (=120+9-12). 

As an aside, when your team is first starting out, you will not have any empirical data or previous actual velocity to work with.  In other words, you will have to guess your team's target velocity.  However, the good news is that because the sprint is often only 2, 3, or 4 weeks long, your team will not have to wait long to learn the team's actual velocity.  This can then be used as empirical data to help you calculate your team's next sprint's target velocity.  

In whatever way you decide to calculate the team's target velocity, ensure that the previous sprints’ actual target velocity is applied in some manner to bring as much empirical data into the calculation.  Also, attempt to apply a consistent calculation from sprint to sprint.  From there, inspect and adapt as appropriate.       

Agile Definition of Done Starter Kit

I often find it amusing when the definition of ‘done’ in Agile is sometimes called ‘done-done’. This is meant to imply that we are not just done with development (the 1st done), but we are done with testing (the 2nd done) as well. However, if you think about all of the activities that are needed to get stories in a sprint backlog into the shape to be potentially shippable, you should probably call it “done-done-done-done” and possibly more (LOL).

So what is the importance of done criteria? First as mentioned, it helps the team understand what is the expectation of getting a story (or the functionality therein) into shape to be potentially shippable. Second, it helps identify the activities and expectations that must occur to build a quality product. Third, all activities in the done criteria are considered when the team sizes the work during Sprint Planning and, therefore, has a direct impact on the sizing of stories. When the team sizes a story, they need to ensure it includes all of the work described in the team’s "done criteria".
 
I usually bring a starter kit of typical tasks to get a story to "done". This helps initiate an active discussion prior to sprint 1 among the team so that each team member understands the various elements of the done criteria and what elements we are agreeing too as a team. Here is my done criteria (aka, definition of done) starter kit:

• Incremental designing (and what type of design type(s) the team will use)
• Incremental development (per the development programming techniques, and this includes developing documentation such as user guides and non-functional requirements associated with the story)
• Incremental building/evolving the unit tests
• Consideration for incrementally building out automation for regression testing, etc
• Applying appropriate source control, checkout/checkin, and branching/merging
• Applying approach incremental local builds (in private workspace)
• Applying code review (or pair programming if being applied) as appropriate
• Incremental testing (per the testing types, e.g., functional, system, integration, etc., pending how much automation there is)
• Meeting acceptance criteria shared by the Product Owner

At this point, the team discusses these elements and establishes a common definition of done for the stories and the sprint. Now keep in mind that this is the team’s common done criteria and it should be flexible depending on the type of work. Also, once the team agrees to done criteria, expect it to evolve over time and it may be a discussion in the Retrospective if it needs improvement. Some of the effort associated with your definition of done is dependent on what tools, infrastructure, and automation, that currently exists and where you want to go, so keep this in mind.

Finally, if your definition of done has nine key activities, then you can call it the “done-done-done-done-done-done-done-done-done” criteria (LOL).  Maybe just one "Done" is enough.  Once you establish the done criteria for the team, don’t forget to evolve it over time to get you to a quality and releasable product!