Impact Over Velocity

Impact over velocity.  In other words, don’t just do things.  Do the right things.  It seems obvious, but how many of us are guilty of deciding the success of a sprint by how many stories or story points we completed?  But don’t worry.  You’re not alone.  Velocity is an easy number to get at, but easy isn’t always best.  Or right.

Before we dive into understanding impact, let’s flip the concept.  What does velocity over impact look like?  If any of these apply to you, it could be a sign of trouble:

• Your team has disjointed or vague sprint goals.  Your goals may have little to do with your team’s mission.  Or they may be so varied or vague that they provide the team no focus, vision, or enthusiasm.
• The team has too many goals.  James Carville once gave Bill Clinton this advice:  “If you say three things, you say nothing.”  Too many goals are noise; they’re overwhelming.  Find out what’s most important, attack it with conviction and discipline, then move on to the next target.  Don’t attempt to do everything all at once, or you’ll end up doing nothing.
• A disproportionate amount of sprint work has nothing to do with your goals.  Maybe your goals rock.  However, when you look closely, do these goals align with everything contained in your sprint backlog?  If half your backlog has nothing to do with your goals, this may be a problem.
• Your velocity metric is overemphasized.  In the absence of other measures of success, stakeholders associate a high number of completed story points with a high amount of impact.  By extension, the team adopts a similar mindset.  Remember that people don’t do what you expect; they do what you inspect.
• There’s little or nothing to demo at the sprint review.  The entire team has been busy.  Days have flown by because there was so much to do and never a dull moment.  Yet, when it’s time to demo another increment of your product, there’s little to show your stake holders.

Let’s be clear here.  Velocity is important; I review my team’s velocity as often as you.  It has value; however, I value impact more.  Unfortunately, impact can be elusive to uncover and sometimes difficult to measure.  It can take any number of forms:

• An increase to the bottom line.  Of course, knowing if you affect the bottom line takes time so you may not know this for several sprints.  Worse yet, some organizations lack the necessary tools to quickly and correctly evaluate the success of new features or changes.  If your company conducts frequent A/B testing, for example, use this information to make better data-driven decisions.  If not, read the Lean Startup by Eric Ries for some excellent advice on this topic.
• Mitigate a substantial risk.  Risks are the things of nightmare for product owners.  It can take the form of a paralyzing software alternatives, the unknowns of a specific infrastructure change, or possibly a lack of an automated test suite.  Set a goal to resolve one of these risks by the end of the sprint.
• Make a painful mistake.  Our mistakes are often our best teachers.  We often invest too much time and energy into getting something right the first only only to learn time and again that we rarely can.  Embrace failure and use it as a benchmark of a successful sprint.  As I’ve said before, fail early.  Fail often.  But never fail the same way twice.
• Increase team morale.  This will look different for every organization.  For ours, it involves periodic, company-wide hackathons and sprint time set aside for team members to innovate on their own ideas.  For a product owner, it may be giving team members ownership over an idea–their idea–that they believe will positively impact the business.  For a scrum master, it may be getting the team out of the office for a team event to build solidarity.

Whatever you do, I hope you agree that impact is more valuable than velocity.  In the words of a wise woman–my Grandma Jo:

If it’s worth doing, it’s worth doing right.

I can’t count how many times I heard this as a child, usually when she was paying me a dollar to wash her car (and usually when I wanted to cut corners just to be done).  It pained me to learn then, just as learning to value impact over velocity pained me to learn as a young scrum master.