Agile Chronicles

What is velocity? Part II

Velocity can be measured in various units - typically story points, ideal days, ideal hours, hours or some other more interesting unit of measure such as gummy bears.  One of the key advantages of velocity is that it is fundamentally unit agnostic.  It does not matter what unit you use to measure velocity, just as long as you remain consistent.

Of critical importance to achieving a reliable velocity is fixed-length iterations - typically from one week to one month.  I often hear teams wanting to significantly vary the length of their iterations to accommodate other internal needs.  There are already so many uncontrollable variables on a software project, why introduce another.  By simply controlling iteration length, we are able to track a metric that conveys a completely accurate and unbiased measure of progress over time.  From this historically accurate metric, you can then begin to reliably predict what your team can do in the future. 

With velocity, we finally have a metric that, for me, has proven exponentially better at measuring project status than the elusive task hour per person per day.  By maintaining the integrity of the metric (e.g., basing velocity on fixed-length iterations), we have a measure that we can actually count on.  If we allow iterations to vary, velocity will never achieve the desired consistency and we are are back to guessing when we will be done.

For more information on velocity, see http://www.versionone.net/Resources/Velocity.asp and/or http://www.extremeprogramming.org/rules/velocity.html.

What is velocity? (or Veni, Vidi, Velocity)

I came, I saw, I measured velocity.

So what is velocity and how does it help?

Velocity is a very simple, straightforward measurement of the amount of work being delivered on a project. Velocity is calculated by summing the estimates of the features (user stories, backlog, requirements, etc.) completed during an iteration. Every iteration has a velocity. Only features that are completed are included in the calculation of velocity. By tracking velocity, a team is able to accurately gauge overall project progress and health.

When I was first introduced to velocity, I have to admit that its value was not at all apparent. Yes, the general idea made sense, but what could it really offer someone with years and years of experience on hundreds of software projects. I do not remember how long it took. It definitely wasn’t just a couple of weeks, but it also wasn’t six months. Somewhere in between, it sank in though. To me, one of velocity's greatest values is that it is a metric that removes most of the gray that permeates each and every day of software development by focusing on the one thing that really matters – working features.

Yes, there are meetings, issues, risks, bugs, changes, tasks, etc., but by tracking velocity, it is extremely easy to tell whether a team is making consistent, customer-valued progress on a project and how fast that progress is being made. Now, on the other hand, someone might not like that rate of progress (which is a different matter entirely), but there it is, a number that tells me approximately how much longer a project will take if I know the total estimate of the project and how much is being completed each iteration. Velocity cuts through the daily confusion and describes, in very simple terms, what is really going on. Velocity is all about project predictability, and that is really what we have been trying to achieve for decades now.

Happy Birthday Agile

So it's been exactly 5 years since that historic meeting of agile minds at Snowbird bestowed upon us our famed Agile Manifesto.  Like a sign from above (Snowbird's Summit is 11,000 ft), a few basic principles and some very loud, persistent ranters and ravers initiated the task of changing an entire industry.  A few simple words and principles in turn gave many of us the ammunition we needed to join in this colossal battle --- "Yea, though I walk through the valley of the shadow of death marches, I will fear no evil". 

All kidding aside, I am certainly thankful to these 17 agile anarchists for their positive impact on the software industry.  Five years later there is both a great deal to be proud of, and a very long way to go.

Here's to the next 5 years!

Finally, Feature Breakdown

So with our latest release, we delivered a pretty cool feature called simply enough, "Breakdown".  As an immediate exception to the rule in my prior post, this one word capture the essence of what our customers wanted to do, so it was good enough for us. By far one of our most requested features, customers just wanted to take big features that they were receiving from marketing, sales, customers, etc. and break them down to smaller features. 

Splitting is one term that has been used in the industry for a while, but did not seem to capture the details of what our customers really were asking for.  They wanted to maintain the integrity/existence of the original mega-feature, but wanted many, smaller stories to emanate (we used the term "spawn" internally just because it sounded way cooler) from this single source-story and to continue to maintain this parent-child relationship.  This could then in turn, happen to additional stories further down the feature hierarchy they similarly proved too large for incremental delivery.  Ultimately you end up with a feature tree that results in schedulable features.

Hopefully we hit the mark, but feel free to provide feedback or ask questions.  We use this internally every day now.

 

What's in a story name - Part Deux

As I was considering my prior post on long, complex story names, I also recalled a potential process smell that can arise from the exact opposite scenario - i.e., story names which are too short.  What's wrong with a nice, concise story name you might say.  Well, maybe nothing, but you may want to make sure you have that conversation with a customer sooner rather than later.  Why, because sometimes "too simple" can be "too open-ended". 

Consider a story name like "Generate Reports" or maybe "Authorize Transaction" (Note: The names have been changed to protect the guilty).  While seemingly innocent enough, it is stories like these that can secretly balloon out of control.  These may serve as reasonable high-level features or epics, but these are also stories that should be highlighted in a way that helps the team know that as soon as they are prioritized for an upcoming iteration or near-term release, that they need to immediately be broken down into lower levels of granularity in order to be able to estimate, test, and deliver the expected value within the iteration.

There are always exceptions to any rule, but just maybe consider that many 2-4 word stories may be "ripe for the splitting" - i.e., breaking down into smaller, more granular features.

What's in a story name?

Everything!  The story name should identify the action being performed, potentially the type of user performing this action, and not really any more than that.  Remember, the story name is a placeholder, i.e., "a contract to communicate" between developers and customers.  The intent of the story name is to initiate a conversation, not describe the feature in detail.  Far too many story names we get to see appear entirely too long and complex.

In our product, we used to have a 50 character limit, which for many companies ultimately just was too short.  While we could easily increase the size, resistance came from our desire not to have customers use story name as more than just a placeholder.  We ultimately compromised [read: caved] by changing the name of the attribute from "Name" to "Title" at least to give a better indication of the use of the field in the system.  Highlight the feature and its intention, but try not to describe.  As with many aspects of software development, the simpler the better - story names are no different.