Velocity Counts in 2014 – A Preview of our Backlog and Commitment to You!

VC’ers –  Happy 2014 from Nick and I.  First off, we’d like to thank all of you for all of your encouragement, support and fellowship in 2013.  We are thankful for your steering and guidance and we are moved by your actions.  In 2013, we felt part of your Agile practice and part of your everyday experiences.  What you shared with us was wonderful and what you delivered back to your organization was great, and, in 2014 we can collectively do better!

Before I go any further, let’s take a minute to thank our fantastic sponsors that allow us to provide all of you with valuable content free of charge!

Appfire - North America's most trusted provider of Atlassian Enterprise Services

Appfire is North America’s most trusted provider of Atlassian Enterprise Services

catch-software-primary-logo

Enterprise Tester by Catch Software helps teams deliver high quality products

practice-ignition-wht

Practice Ignition is the #1 tool for the modern accounting practice

What an exciting year ahead!  2014 is going to be nothing short of electric.  During the holiday break, Nick and I were hard at work coming up with an editorial calendar that will finally help you and your organization deliver against the intended promise of your Agile implementation.  We both know that you are not delivering your best and we aim to change that.

Thanks to our sponsors the free content we provide will:

  • allow your Agile implementation’s to become more stable and scalable,
  • make teams more predictable,
  • increase quantity and quality of output,
  • strengthen intra and cross-team collaboration,
  • increase team velocity,
  • allow individuals to achieve peak performance (their Nirvana state), and
  • help teams deliver substantial value back to your customers

Our Definition of Done for 2014 is simple:  Nick and I want to see an immediate and sustaining increase in your velocity.  Dare I say the obvious:  Velocity Counts!

Nick and I have never been this excited to write about content in the Agile space.  There is quite honestly so much going on in this space, that it’s hard to pick areas of focus.  Sadly, we must.  In order to keep our promise and deliver against our definition, we need to be laser beam focussed on the development of content in our areas of expertise.

In early 2014, Nick is focussed on creating content that will help: your teams take shape, move directionally, and create environments that inspire the very best from your teams.  This year, I’ve got my mind wrapped firmly around content that will grow individual performance.  I want 2014 to be your best, which requires you to be at your best – in order for you to deliver against the commitments you are making to your teams.  I’m going deep inside you and that giant brain of yours to make some much needed adjustments.  I’ll help improve your personal velocity and in doing so, your health and behavior.  Definition aside, expect nothing but one hell of a year at Velocity Counts! 

Now, more than ever, Nick and I are interested in hearing what you and your team are up to.  If you’re stuck on something, have a burning question that’s been haunting you, or have an ingredient of your own that you’d like us to share, simply Tweet @VelocityCounts or comment below.

Cheers,
Randall and Nick

A Daily Scrum can be Strategic!

I’ve spent a good portion of the past 11 years as a product coach, working to introduce scalable agile techniques to hundreds of product engineering teams.  My work has brought me around the globe in pursuit of helping enterprise teams accelerate product development, doing so in a manor which helps increase individual performance and promote healthy interactions.

In my travels, I’ve met some amazingly talented and creative product teams, and as you might imagine, my sessions with these bright contributors are often filled with insightful interactions and meaningful exchanges.  More often than not, I feel as though I’ve left with more gained than I’ve imparted.  There could be no better reward for a coach and just recently, I had one of those sessions.  However, this was not the typical session.  There was no classroom, the instructors were not product people; and this time, I was the student.

Etched at the top of my notepad that day was:  “Daily Scrum can be Strategic!“.  I’ve been practicing Agile since the signing of the Manifesto, so one would think that by now I would have already learned the values of a Scrum!  Believe me, I was just as surprised.  Equally surprising if not shocking was the fact that I learned it not from an engineer, not from a product owner, or even someone in the product world at all.  I learned an very valuable lesson on Scrum from an athlete.

Sitting in an airport lounge having been delayed for several hours, I struck up a conversation with two gents who were scheduled to depart on the same flight.  Both traveling towards the States and both interested in why I was connecting my Mac to a banana and orange.  Having explained Makey Makey as if I were talking to two electrical engineers, they stopped me and said “… we have no idea what you are talking about, but controlling donkey kong with fruit is awesome!“.  I quickly turned the conversation back over to them.  I asked them where home was and whether or not travel was for business or pleasure.  They both said that they were more into sports than computers (I had my suspicions).  I asked them what sport and one of them quickly replied rugby.  As it turns out, both were on the USA Rugby Team, traveling back from the Sevens tournament.

The Outrigger on the Lagoon – Fiji So Close in the Coral Coast Sevens!

Half jokingly, I then said: you know, we have something in common.  “… You play rugby?” one of them inquired?”.  Hah.  No, I replied.  I told them that although I don’t play the sport, I have studied rugby as one part of the game often makes it’s way into my work as a product coach. I then went on to describe Agile Scrum and the typical activities that occur within a daily Scrum.  One of them piped up and said, “..but it seems you have part of it wrong!“.  Oh?  Thinking to myself, how could I have it wrong?  I then asked:  Which part?

They both went back and forth for a few moments describing what takes place within a Rugby Scrum and in essence what they described was the fact that not all of the moving parts and team interactions within a Scrum are meant to be tactical in nature.  What they described was that the actions and techniques, which formed the basis of a play were more strategic than tactical in nature – in fact far more strategic than they appear in real-time on the field.  Both emphasized that the goal wasn’t just about moving the ball forward.  It wasn’t always about “this play“, or “this portion of the field“, or “what the current scoreboard reflected“.  Sometimes the situation called for more strategic thinking.  The kind of big picture thinking that wins games and not just plays or position.

WOW!  I was speechless.  For two guys who struggled to understand microcontrollers and simple circuitry, they certainly had a way of connecting the dots with Agile!  For years I’ve struggled with how to keep teams thinking big picture, while driving ceremonies centered around small parts of a larger whole.  Is it possible that through airport conversation, I inadvertently found a solution?  While boarding the plane, I couldn’t help but smile.  Who better to teach me the true value of a Scrum than members a Rugby team!

Do you struggle with keeping your team focussed the big picture, while working continuously in “the now”?  If so, have you changed or altered your ceremonies in a manor which stimulates strategic thinking?  One idea that Nick and I have been discussing, is to possibly add a fourth question to your daily Scrum.  So in addition to the typical three, how about adding #4 to the list:

  1. What did you do yesterday?
  2. What will you do today?
  3. Are there any impediments in your way?
  4. What strategic things are you thinking about / working on?

Eliminate Free Radicals – A Path to Scaling Agile in the Enterprise

You might remember from chemistry class that a molecule can exist without a paired electron, making them highly reactive. Molecules fitting this description are considered “Free Radicals“. What your professor may not have told you (mine certainly hadn’t) is that Free Radicals (or Radicals as I like to refer to them as) also exist in human form and unlike their scientific brethren, they often appear in clusters, especially within large organizations. While they may play an important role to science, I’ve always placed the human version at the top of my list of reasons preventing Agile from scaling within large enterprise.

Characteristics of a Free Radical

I have some great news for you. Free Radicals are extremely easy to recognize within your organization. Here’s a list of characteristics and mannerisms to watch for:

  • Every task they represent to the organization is urgent and a top priority
  • They do not use a consistent medium to communicate information
  • It’s not easy to recognize any direct contributions they make to the organization
  • They don’t want to take time to learn about the methodology you work within (e.g. Agile)
  • They submit requests just short of the due date
  • They echo communication across many channels (e.g., email, IM, phone, etc)
  • They are quick to offer compliments privately, but never in public forums
  • They are indecisive
  • They are often the center of conversations with conflict
  • They wander the hallways with lemon water in hand (a tangental observation)

Free Radicals can Squelch Agile Adoption

When I speak or meet with Agile coaches or any executive looking to adopt or grow their Agile deployment, I begin with a cautionary statement about Radicals. Their meer presence, no matter the number, can quickly squelch Agile adoption. Therefore, you must develop a plan to insulate yourselves (see below). By exerting their own chaotic manor of work, Radicals squelch Agile adoption by:

  • With Scrum teams – Insisting that changes be admitted to active Sprints (e.g., backlog promotion / scope change mid-Sprint)
  • With Kanban teams – Insisting that their items be expedited and change SLA course
  • Not accepting deliveries against their agreed upon definition of done
  • Frequently interrupting team members
  • Forcing exemptions to be from an accepted list
  • Contributing to the delay of requirements definition
  • Refusing to obtain status updates from systems or boards, preferring them from people
  • Breaking cadence (our internal rhythm)
  • Contributing to friction and causing frustration

Insulate and Scale

Ahh, recognize them now – don’t you. Worse, you realize that Radicals are all around you, possibly looking over your shoulder right now? Relax, they don’t like to read from a far, especially articles with the word “Agile” anywhere in the title. There are three simple ways to insulate your teams and reach scale – and even better, a simpler way to remember them. You WOW them. Walls, Obstacles and Warfare. I developed this strategy years ago and it’s something that I’ve continued to practice and introduce to hundreds of Scrum teams operating within enterprise-size organizations.

Walls

I’m not talking about the physical here. Unfortunately building codes and the such require that you have adequate doors and means of egress. Admittedly a slower life form, Radicals have evolved to a point where they have opposable thumbs and can navigate simple obstacles quite readily. As an Agile organization, everyone on your team needs to be comfortable saying no to requests which challenge the methodology in which you work or jeopardize the working agreements you have in place with other departments / divisions. For humans, it’s often hard to say no and Radicals can make this harder and outright uncomfortable at times. You need to have a common redirection in place, one that everyone on your team understands and feels comfortable using. The key is that everyone must respond in the same manor and provide a near-identical response. It won’t work unless this is the case. An example of this redirection might be: “Sorry, we are in feature freeze right now, so I can’t make additional changes without jeopardizing the project schedule. You need to talk to <INSERT The Big Boss HERE> if you want that change made”. Radicals will hear this and then check with the next team member, and the next, and the next… and so on. They are looking for a weak link in the chain. If they receive the same response, take my word for it, they will go away.

Obstacles

I’ll be the first to admit, Radicals from time to time will have a valid reason for causing an interruption or asking for an exception, etc. When this occurs, we still need to steer them towards a less-chaotic manor of introducing the new work stream. In other words, let’s not just stop what we or everyone is doing just because they are in possession of a valid item of work. As an Agile organization, we need to have a well described process of how we accept work, what details are required before we will evaluate, how long it will take us to respond, how we will respond, etc. Effectively we are sharing the teams working agreement with other parts of the organization. The process of handling exceptions needs to be clear and available to all, so making it part of the working agreement makes sense. The working agreement is a living document that your team visits as part of your retrospectives to see if there are opportunities to modify and strengthen the contents. An example of an obstacle might be the fact that your team will not accept any User Interface (UI) items without prior receipt of PO sign-off against User Experience (UX).

Warfare

Let me guess, you skipped ahead to this section didn’t you? If you did, it’s alright, but please go back and read Walls and Obstacles first. Ok, welcome back! The first two-thirds of this strategy are highly effective techniques at protecting your Agile deployment and teams from Radicals, they should be employed first and then we move to the last stage of our strategy. It’s time to rid your organization of Radicals. Trust me, it can be done. Here are some simple and proven methods to handle the job:

  • Every month, make it a goal to take a Radical to lunch. At lunch: (a) explain Agile and how your teams have adopted from 10k feet and (b) let them know in no uncertain terms, that the better they follow the process, the more work will get done for them (e.g., bribe them).
  • When a Radical follows the process correctly (listens to Walls, navigates Obstacles), go out of your way to recognize their act and do it in a public forum. Reward positive behavior and discourage Radical behavior. (Yes, the same applies to puppies).
  • Publish a list of work items completed, grouped by Radical in descending order. Display this list in a public location (e.g., Wallboard). Peer pressure will help foster non-Radical behavior.
  • If Scrum, then invite them to join a sprint review / demo, give them a front row seat to view potentially shippable product first.
  • If Kanban, them join your team when reviewing team activity. Demonstrate how the team pulls items through stages of completeness.
  • Offer to help a Radical organize and map their teams chaos into an Agile framework. Maybe show them Scrum or Kanban applied to their world. I’ve converted dozens of Radicals using this simple technique.

In other words, the best way to rid your organization of Radicals is to help them grow their knowledge of the way your teams have elected to work. By doing so, you are helping to retrain them and making their job and others more enjoyable in the process.

Does your organization suffer from Free Radicals?  If so, how are you handling them? We’d like to know, share your perspective in the comments below. Want to learn more about high performing teams? Follow @VelocityCounts for the latest blogs and podcasts.

 

Is Burnover Preventing your Team from Achieving Consistent Velocity?

Burnover.  Another name for Stories or backlog items that are incomplete at the end of the current Sprint and fall into a subsequent Sprint.  Call it what you like, but if you want to reach your Agile Nirvana, then you need to develop better recognition, techniques for handling, and methods of prevention.  If not, then you risk introducing frustration, finger pointing and even issues with team morale.

Does this happen to others?

Absolutely.  It occurs more frequently than one might think.  No matter the experience level of a Scrum team, Burnover will occur.  For teams and organizations early to Agile, this is quite a common outcome and can hinder adoption.  I’ve witnessed many situations where Burnover was sited as an example of why Agile wouldn’t work within the organization and why they had to fall back to <insert another non-effective methodology here>.

What Causes Burnover to Occur?

Good news, it’s real simple.  Most of the time Burnover is your fault!  When I say “you”, I mean your Scrum team (the collective you).  For whatever reason, your team wasn’t able to deliver against your commitment.  The three most common causes that attributed to Burnover are:

  1. Overcommitment – This is the result of fairly classic human behavior.  As humans we want to help.  We want to sign-up for more, always.  It’s how we are wired and actually a very important and helpful behavior, but one that requires some reigning in.
  2. Misestimation – Estimation is a art and one that frankly I’ve struggled with in the past.  It requires technique, practice and a good deal of patience in order to perfect.  Experience and conscious measurement will help you get better with this.  It’s very important to recognize that certain team members will be better at this than others or gaining consistent velocity can prove difficult.
  3. Impediments – Stuff happens.  We are advancing product and technology at such a fast pace.  There are many moving parts, teams are collaborating and integrating – and because of this we often uncover surprises.  Sometimes these impediments prevent forward progress and result in Burnover.

During your retrospective, it’s important to assess each Burnover Story or backlog item, classifying it as one of the categories above.  Knowing the source will better help you prescribe a remedy.

How to Properly Handle Burnover?

Because this will happen, you best know what to do with Burnover Stories or backlog items.  First of all, don’t ignore Burnover or sweep it under the rug.  Regardless of how you feel, ignoring or hiding will only increase frustration and prolong your teams ability to achieve consistent velocity.  Here’s a quick five-step guide on how you should handle Burnover:

  1. Because the Story or backlog item was incomplete, it’s Story points do not count against the Sprint.
  2. The Story or backlog item needs to be moved into a future Sprint or into the backlog.  You shouldn’t make the assumption that it should automatically move to the next Sprint.  Consult your Product Owner and team to find out if the remaining tasks (assuming some had been completed) are still higher priority than other backlog items.
  3. Opinions vary sharply on this, but personally I prefer to “clone” each of the incomplete tasks for an incomplete Story to move to the next Sprint or into the backlog.  This way, we can report against tasks that were completed within each Sprint.  Some tooling will let you track and record this without the need to clone.
  4. Your team will need to review the estimates assigned to each cloned task to ensure that the original estimates are still accurate and the remaining time will need to be reset.
  5. Your team capacity for your subsequent Sprint with the newly added Burnover Stories or backlog items will need to be adjusted.

Tip:  I like to color-code, tag and/or label Burnover Stories and backlog items, so they can be quickly filtered from the active list of committed items within a Sprint.  It’s good to keep a watchful eye on these in their subsequent Sprint, so we don’t repeat and push forward into additional Sprints.

Tips for Preventing Burnover

Impediments aside, you can prevent most Burnover from occurring in the first place.  Prevention starts with historical analysis of your past Sprints.  When coaching teams, I’ll typically build a quick scorecards or something I call a “blame pie“.  It’s a simple pie chart that  assigns historical totals (output as percentage) against the three types of Burnover (Overcommitment, Misestimation, and Impediments).  Using this simple chart will help you focus your attention towards some corrective actions.  

Let’s assume for a moment that your blame pie indicates that the largest percentage of Burnover is attributable to Overcommitment.  In this case, then as a team you need to decrease Stories and backlog items being committed to each Sprint.  While that’s fairly obvious, what I typically see teams doing is guessing at the frequency in which to dial back their commitments.  The method that I find works best, is to have your team commit to their historical average, less the historical average Burnover.  Repeat until you are delivering against 100% of your commitments.   

What if your blame pie indicates that your largest percentage of Burnover is attributed to Misestimation.  In this case, you may need to perform some additional analysis.  To grow your teams estimation skills, you need to find out the types of Stories and backlog items where misestimation is occurring.  Once isolated, look for patterns and find a way to describe or personify the Stories or backlog items along with actions your team will take when they come across something similar in the future.  For example, maybe you find a Story that was “Way too large” and really should have been broken into multiple smaller Stories.  Develop a “Way too large” persona for this Story and describe the characteristics and the action of breaking the Story into smaller portions.  Or maybe you find a task that is not very common, but always takes your team longer than expected because they forget how “Uber complicated” the details are hidden within the task.  Develop a “Uber complicated” persona for this task and make sure you indicate that the estimate should always be higher than the initial value assessed by the team. Once you have a series of persona’s, make sure you publish them in a manor where it is easy to reference during your planning / commitment meetings.

It’s unlikely that Impediments are top on your historical blame pie.  Not to say it doesn’t happen.  I have come across this on rare occasion.  True impediments are difficult to predict and therefore prevent.  However, I do have several suggestions for how to deal with them and will discuss this in greater detail during a future post.  For now, let’s have you focus on reducing and ultimately eliminating Overcommitment and Misestimation from the mix.

Does your team experience Burndown?  If so, what are you doing to mitigate?  Please share your experiences via comments below or [email protected]

Enjoy this post? React on Twitter:

Planking and its Impact on your Agile Team

New Scrum teams may find meeting their sprint commitments hard, it can be awkward at first! In this post Randall explains what planking is and how to avoid it.

I’ve been an avid hiker since my 8th birthday, the day I got my first new pair of hiking boots. Ever since, if I have time and a trail to hike, I’ll make a go at it. By 15, I had hiked one-third of the Appalachian Trail, which totals 2,200 miles (3,500 km). I trekked North-to-South, a stretch from Mt. Katahdin located in Maine all the way to Maryland. I’ve hiked nearly all of the major ranges in North America, including my favorite the Philmont range located in New Mexico. Early on, while hiking with a good friend and lifelong mentor Yiao-Tee, I learned a very valuable lesson that not only applies to the activity associated with hiking, but one that I’ve carried forward and applied to many other personal and professional activities in my life. The lesson was: to keep a consistent pace, a continuous rhythm only stopping for physical and biological necessity (e.g., shedding / adding layers, hydrating, avoiding danger, or other must-have biological functions). This lesson came as we were ascending above tree line and he saw that I kept stopping every quarter to half mile, insisting that I was gased and needed to rest. Yiao explained that this behavior was more mental than physical. My mind was telling my body to stop and not the other way around. It was in my head. I listened and out of respect, I acknowledged – but I’ll admit, I thought he was wrong.

Fast Forward – Agile Coach

The Company:  Iconic Automotive Company
The Project: Rebuilding the legend of a muscle car in modern day
My Title: Drive fast and take chances (Agile Guy)

At the time, Agile was a very new concept. Ink on the Manifesto had barely dried. With a strong background in Lean Manufacturing and XP, Agile stuck. I’ll go as far as saying it made more sense than any software or product development methodology I had previously used. Locked away in a private warehouse with an incredible team of engineers, we began re-imagining the dream of our Father’s and Grandfather’s generation. The soft click of a key, grind of the starter engaging, the pulse the intake valve gasping for air and fuel, metal on metal as the piston compressed this mixture, a short volt and finally combustion! Sound from the exhaust that would wake neighbors or let friends know you had arrived. Ahh, the muscle car. This was now our dream to conceive, but the catch was we needed to produce working results in 18 months, roughly half the time of standard vehicle production (concept –to- launch). This was a fixed date project, with commercials, marketing and the like all lined up. There was no slipping and no turning back.

What’s Wrong with Us?

We discovered quickly that meeting our Sprint commitments was proving to be more difficult than designing and building a car. The car stuff was their job to figure out. Mine was to figure out why we were failing our plans. Our team was running two week iterations which fed into one month increments and then upstream into project phases. While staring aimlessly at our paperboards and daily burn-down charts fashioned from the back of empty pizza containers (big on hiking, bigger on recycling), a pattern emerged. It’s a pattern that many years later I coined “Planking”. It’s easy to spot and was right there all along, but I overlooked it.

Example of an agile team planking, shown on a JIRA burndown chart

The image above is a burn down chart taken from a project being tracked within Atlassian JIRA. The image depicts Planking, where there was a 4.5 day period of time with zero Stories being completed.

The Discovery

At a varying point in all of our Sprints, I noticed there was a period where no team members were completing Stories. It ranged between 2-4 days, but always present. 29 superstar engineers slowing down at nearly the same point in time each Sprint. None of the pauses were associated with impediments.

I discovered through a series of experiments that our team was the cause of the Planking. Their minds were telling them they needed to pause, break stride and slow momentum. Although everyone had a valid reason for not burning their particular issues during the periods of time, the reasons boiled down to “excuses” that satisfied their want/desire to stop and pause. The team wasn’t underestimating effort, they were Planking.

Prevent Planking

Once discovered, I brought the group together and explained the findings. I mentioned what Yiao had taught me while hiking as a child. In an effort to prevent, we evolved our process and made the following changes:

  • Instead of a Pizza box, I plotted our burn down chart on a large concrete wall using bright sidewalk chalk. We opened our morning Standup by reviewing the burn down as a team. Transparency and awareness of the chart proved incredibly valuable.
  • Instead of pulling Stories from our committed Sprint in order of Business value, we began each Sprint by working on the most complex Stories (where possible). This “eat-the-frog” pattern allowed us to work forward through each Story with the feeling that we were gaining momentum (as the Stories decreased in complexity). I’ll cover this concept in more depth during a future post.
  • I drew a large circle on the bottom of the warehouse floor, just beyond the threshold entrance and in the center I put the number of days since our team had last Planked. The entire team was forced to view each morning as they began their day, reminding them of the challenge we had put behind us.
  • We heckled our colleagues during the morning SU (stand up). Anyone who didn’t burn in a 24 hour period was forced to lean a large 2x6x6 piece of lumber (our version of a plank) up against their desk, almost like a flag indicating they hadn’t burned.

Has your team experienced Planking?  If so, I’d like to hear about it, share your experience in the comments below or tweet @VelocityCounts.

Measuring the Velocity of Agile Teams

Velocity. By far the single most important word to any Agile team. Whether you are currently practicing Agile, looking to adopt within your organization or trying to achieve your Agile Nirvana, understanding Velocity is fundamental to achieving success with Agile.

Velocity.  By far the single most important word to any Agile team. Whether you are currently practicing Agile, looking to adopt within your organization or trying to achieve your Agile Nirvana, understanding Velocity is fundamental to achieving success with Agile. Beyond a basic understanding, it’s important that you learn how to measure, influence and improve upon it. Velocity is a point-in-time metric (unit), used to accurately measure the value that your product development teams are delivering to your business.

Calculating Velocity

Calculating your Agile teams Velocity is quite simple. Just sum the total estimates (story points, days, ideal days or hours) of user stories, requirements or backlog items that were delivered and accepted within a prior Sprint (iteration). If this is your team’s first iteration you can still plan your initial Velocity. A good rule of thumb when using time-based estimates (e.g., days, ideal days, etc) is to plan initial Velocity at one-half your team’s total available time. When doing so, keep in mind that you need to account for overhead (e.g., meetings, email communication, documentation, etc.).

For example, let’s say that you are using an iteration length of two weeks and that you are working with a team of four developers. Using this example, you would be working with a total of 40-days (4 developers X 10 working days). Applying the rule of thumb above, your team would ideally plan the iteration with 20 days of work.  Using story points as your estimate?  I’ve found that using roughly one-third of total story points planned is a great place to begin for most teams.

Using Velocity Charts

Like burndown charts, velocity charts are invaluable as they provide insight into how a team is progressing with their current and any previous iterations.

Velocity Chart from Atlassian JIRA

For each iteration, a typical velocity chart will show the sum of estimates committed against the sum of estimates delivered and accepted. Velocity charts can help your teams plan more accurately. They are easy to produce, so whether you are using a tool with this feature built in or not, you should take time to produce one for each iteration.  The image above is a velocity chart taken from a project being tracked within Atlassian JIRA.

Using Velocity as a Guideline

It can take several iterations for before your teams velocity stabilizes, but from the very first iteration onward, your teams should be using the velocity of your prior iteration(s) as a guideline to help steer planning sessions and influence team commitments. When first adopting Agile, it can be difficult to contain the teams desire to overestimate their velocity. This is natural and actually something rooted deeply in human behavior. The best way to prevent it from occurring is to temper your commitments by using the teams own historical velocity as a guideline. It’s certainly okay to stretch and grow the teams velocity if you are consistently achieving and/or exceeding your commitments as long as it is supported by your historical velocity.

Keep Velocity Simple

Velocity is a fairly simple concept. It is easy to measure and track a teams velocity over time. This is actually intentional and much of the value comes from the fact that velocity is straight forward and easily understood.

Some teams we’ve worked with get this wrong – they overcomplicate their velocity measurement. One way to keep the understanding of this Agile metric pure and simple, is to write down the meaning and have it physically present above locations where a team’s velocity is out on display.

Stable Velocity leads to Predictability

When an Agile team achieves a consistent velocity over time, their velocity becomes “stable” and in turn the team becomes predictable. Teams that are predictable make it easy for a Product Owner (PO) or set of stakeholders to assess the delivery date for a fixed scope product backlog, or even a portion of the backlog such as an Epic or series of Epics.

When working towards a fixed date product release predictable teams have the confidence to make commitments to customers. They also have the ability to have a discussion about features vs time trade-offs as they have a greater understanding of their cadence and capabilities.

Predictable teams:

  • have a consistent rhythm and cadence that others don’t,
  • help to motivate other parts of the organization,
  • collaborate more effectively amongst themselves and with other parts of the organization,
  • ship product!

So, what’s holding you back from measuring your teams velocity? If you don’t measure it you can’t improve it1.

  1. William Edwards Demming []