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 Problem Finder

I occasionally hear that Agile is the silver bullet and will solve all engineering problems. In some cases, someone in management heard about Agile and figured it could be a quick fix to solve the challenges within their organization. Unfortunately this is far from the truth. While Agile mindset and methods can help you adapt to customer needs and deliver more effective customer value, one key benefit that I find is that Agile shines a bright spotlight on existing problems within an organization or team.

This is where Agile methods such as Scrum, eXtreme Programming (XP), Kanban, Test Driven Development (TDD), and others can be very effective problem-finding tools. While this is not what most people think about when adopting Agile, it is a side benefit. It is important to understand that Agile methods won’t necessarily help you solve the problems that are being uncovered but they really need to be removed to achieve the value delivery and speed you are looking for. 

More often these challenges have been around for quite some time, well before Agile was introduced. In fact, management and team members have known about these issues, risks, and dependencies, but they conveniently get buried under the organizational carpet. In the Agile world, every impediment can impact the value and velocity of Agile.  Once Agile comes along, the spotlight focuses brightly on anything that gets in the way of efficient and effective delivery of customer value. What are some of areas where Agile shines the halogens onto existing problems? In my experience, I have encountered numerous challenges during the deployment Agile. Here are some examples:

• When moving to a 2 week cadence of delivery, the team bumped into organizational processes like approvals and alignment of priorities that slowed the team's ability to delivery on a faster cadence. We talked with these approval groups, shared what is agile and asked if they could work with us on a more regular basis (e.g., bring approval groups in earlier and add a Scrum of Scrums to gain alignment with dependent groups).  
• In setting up Scrum teams, it became clear that there is a lack of QA resources on the project (7 developers to 1 QA engineer). We assessed that our development to QA ratio really needs to be 5 to 3, then replaced some developers with QA engineers. Until we could hire the level of QA engineers needed, we had a few of the developers play the QA role.
• We learned that teams often don't stay together long enough to perform effectively.  Project-based company didn't allow bonding time. When the project ended, the employees are reconstituted to other project teams. We worked to have a long lived team allowing them to go through the stages of forming, storming, norming, and then performing and then stay together. 
• The team lacked trust and psychological safety. There is often a culture where trust is damaged by management actions as teams are not trusted enough to make decisions. Teams don't feel safe enough to bring up vulnerable points to more easily get over team hurdles. We implemented bounded authority so teams own their own decision-making.  
• In running incremental QA processes, it becomes clear that there is a lack of automation and, in fact, very few unit tests were ever written. We then spent some time building unit tests to provide at least 80% test coverage (we built this into our Definition of Done), then began automating the tests.
• In running continuous integration, there was a lack of understanding the branching and merging process. Developers were unaware of the importance of refreshing the private workspace with latest successfully built and approved code and also continued to retain local objects and executables in their private workspaces. An effective Checkout/Checkin process (with refresh and build and promote) was established and workspace education was conducted by the Configuration Management (CM) engineers for the team.
• In working with a legacy team, it became clear upon sizing and building functionality on existing code, that we were continually breaking other parts of the code since there was tremendous technical debt within the code base. It was learned that there was no coding standards since the beginning. We initiated a refactoring strategy with coding standards to help us reduce some of the more problematic code modules.
• In working with Product Owners (aka, Product Managers), it became clear that requirements were poorly written which led to a lot of churn between the Product Owner and the developers/QA engineers. The existing requirements list had requirements at multiple levels and it was hard to discern who the requirement was meant for. I educated the Product Owners and Scrum team members on how to write requirements in a canonical form (persona + action + business value) and the POs rewrote the requirements over time in a priority order.

For some teams that move to Agile, they can get overwhelmed by the problems that are identified by the Agile spotlight. In some cases, prior to deploying Agile, it is worth identifying the existing challenges so folks realize they are not caused by Agile. One way to do this is to understand your full end-to-end "idea to release" process. The key is to add the challenges to your issues list, prioritize them, then address them in priority order. Remember, the Agile spotlight can help you identify some of your problematic areas on the product or in the organization. Take advantage of this but be prepared to address the challenges.  What existing problematic areas have you identified when you were implementing Agile?

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!  

Agile – Its more Disciplined than you Think

Agile is known to be an adaptive mindset and approach to conduct work to better align with customer needs.  A side affect and often a myth to this is that some think Agile allows ad-hoc changes and it gets branded as being the cowboy methodology. Some folks who say they are Agile, use it as an opportunity to abandon processes and documentation so that they can enjoy the wild west life. These cowboys know that they get away with pretending to be Agile since many folks, particularly their up-line management have little idea of what Agile really is. Other folks like to term whatever they are doing as Agile in order to be on the Agile bandwagon.

However, it is the cowboy and those that want to pretend they are doing Agile that propagated the myth that Agile is an undisciplined approach. Ultimately, these pretenders can give Agile a bad name in the organization and industry since others will believe that Agile means no process, implies an ad hoc approach, and is undisciplined.

For those that have followed the formal Agile approaches of Scrum, Kanban, eXtreme Programming (XP), Test Driven Development (TTD), and more, when done right realize fairly quickly that Agile instills much more rigor and discipline than some folks realize. Some who follow Scrum properly for instance, learn quickly that there is much more discipline than they originally thought.

One of the early introductions to Scrum is Sprint (or iteration) Planning.  Imagine every two weeks you revisit the backlog to reprioritize it, then scrub and design each story, size the work, and commit to the work for the next sprint. This is meant to be a rigorous day of really understanding the work for the sprint where typically your brain will hurt upon conclusion of this day-long session!

Now let’s visit the Daily Stand-up sometimes known as the Daily Scrum. First, imagine that you MUST show up on time. This shows your commitment to schedule and respect for others' time. Then imagine you must share 'what you did yesterday' and 'what you are doing today', and “what are your impediments” and not just to the Scrum Master but to each other. Imagine, every day this is occurring! This starts to get you into a laser focus of the work and gets you motivated to get work accomplished.  

Finally imagine that at the end of each sprint, you must have working software per the end of sprint review (aka, demo). This means that within the end of a two-week sprint, you need to build the user story (aka, requirement) into a meaningful and viewable piece of functionality for validation by customers (and you cannot show customers junk, can you?). Remember that Agile takes an empirical approach where progress is based on actual observations and data to understand progress. 

To add to this, during the sprint each story you work on has to meet the rigorous “done criteria”. Done criteria is a commitment that (for example) each story that is worked on, must be checked out, incrementally designed, coded (following appropriate coding standards), possibly code-reviewed, built, unit tested, checked-in/promoted, merged, integration built, smoke tested, and system tested. Whew, is that enough discipline for you yet? All of this within a sprint so that you can have some tangible to show the customer so that they can validate if you are meeting customer needs.

Or course there are many more rigorous Agile practices. The discipline helps with the productivity and accountability to really become an empowered team. The discipline also ensures you remain hyper focused on the work. So next time someone says Agile is undisciplined and ad hoc, it is clear that they haven't done Agile as it was meant to be, and more importantly, explain to them the real rigors of Agile when you want to have observable progress. 

Agile Value Capture Metric - Are you spending your time Building Value?

When applying an Agile mindset, a team should consider the value of each task that they are working on.  Agile often brings value concepts into play and determining the value of tasks is one way to achieve this.  Is the task considered value-added or non-value-added.   Sometimes folks have a hard time wanting to separate tasks into value and non-value because it highlights the non-valued tasks folks are doing. However, if you really want to know, then you must do this (typically at the Product team level).  Sometimes the answer surprises people.   

Keep in mind that in Agile, value-added tasks refer to only those tasks that are directly related to building the product and that your customer values.  This would primarily include user stories and the attributes of this work related to the “done” criteria (e.g., incrementally designed, developed, built, tested, etc.) in order to complete the user story.  Remember, value is from the customer's perspective.  

On the other hand, non value-added tasks do not contribute directly to building the product.  There are tasks that are out-right of no value including administrative related tasks, writing status reports, all-hands and other status meetings.  There are tasks with no direct customer value but have benefit to quality including spending time on correcting defects, tasks related to technical debt, performing refactoring. Please understand, there are levels of internal value in doing these things and the goal is to make the value levels of the work transparent. 

A good practice in Agile (e.g., value capture metric) is to capture all related work or activity a team does in a sprint (as backlog items) to understand what are value-added tasks vs the other tasks that we do.  For each story or backlog item, assign it an attribute of either “value-added” or “non-value-added”.  You can track this on a sprint basis (or release basis) or trend it over time (from sprint to sprint).  This is a team-based metric so it is for the team's eyes only.  Below are some examples:

Chart 1: Value of work per Sprint (can be rolled up to the release level)

Chart 2: Value of work per Sprint (at the detailed level)

Chart 3: Value of work from Sprint to Sprint (Trend line)

The big advantage of this type of metric is that it helps you 1) be aware of the value and non value related work that your team is doing and then 2) it allows you to make adjustments if you want to get to a more value-added stream of work.  Also, an important caveat: this metric is a team-based metric and not meant to be shown to management.  It is for the team to see where their work is being spent.   

Whether you call it value and non-value work, the key is that much like the prioritization of the backlog, that you become aware of the priority of the various types of work that is occurring on your team. This metric also brings transparency to the types of 'work' where the team members are spending their time.  While this may force you to make some tough decisions (what is value-added and what is not), it will be worth it in the long run to get your team more productive and focused on the value-added work for your customers.  This can help you on your Agile journey!