I wrote recently about sustainable development and wanted to follow this up with a piece focused around something we’ve been talking about a lot on the project teams I serve as a product owner: how can we understand and increase our velocity?  Velocity is about the productivity of the development team and this can be difficult to measure, in part because for those not intimately involved in the coding process it can be hard to understand what true productivity looks like.

Figuring out the best way to measure productivity or to calibrate a team’s velocity is a tricky and nuanced process.  It can’t be as easy as measuring lines of code.  With the Agile value on simplicity, we know that a simpler and more elegant solution may take longer to write than one that uses more lines of code but relies on bulkier processes.  Is velocity about the speed of rolling out new features?  Is it the number of tickets closed in a given two-week sprint?  The number of bugs found and fixed?  None of these measures quite capture the idea of evaluating how productive a development team has been over a single sprint or over a set of sprints.  Complex features take longer to develop, and the development process sometimes involves kicking ideas around for a period of time before starting on actual coding.  Sometimes collaboration and innovation allow teams to uncover great solutions that can be implemented rapidly, and other times new development and maintenance work involve a steady chipping away at larger problems that seems to display limited visible progress for weeks.

We have not fully solved the question of the best way to measure velocity in my current firm, but we are increasingly using the concept of story points.  This is a common Agile approach and you can find lots of discussion about story points on the web; here’s a link to a good conversation about the merits and problems of using story points that I stumbled upon the other day: http://bit.ly/1eMc27D.  The two main things I like about story points is that they tie back to user stories – the market problems we are trying to address with our development work – and they capture the idea that some problems are more complicated to solve than others.  If I as a product owner can talk through with the developers the goals behind a given user story so that together we can come up with some estimate of how big an effort will be required to solve the problem, then we can assign some point value to the story.  Then when we plan for an upcoming sprint we can determine how many ‘story points’ the team can handle and place the best set of user stories on the sprint backlog.

As a brief side note, this is not the same thing as using story points to build a comprehensive Gantt chart of the sprint work planned for months to come.  Agile emphasizes the need to regularly re-evaluate priorities and to expect occasional shifts in direction as either tasks take longer than expected or new market intelligence surfaces better ideas to invest in.  Story points are a useful tool in sprint planning but no substitute for the collaborative work that comes as the whole team discusses their actual daily effort and the responsiveness of the market to current and upcoming development work.

Story points have their shortcomings of course.  They suffer from the same complications that all estimation techniques encounter, chief among which is the problem that only very detailed estimates are truly accurate – but very detailed estimations take almost as much time to create as doing the work itself would take.  Agile acknowledges that once a project is begun new information will emerge about the best path to a solution; sometimes this new information will illuminate better and faster solutions than expected and other times this new information will reveal previously hidden layers of complexity that will take longer to work through than expected.  Estimates are just that – approximate measures of effort based on available data that will change as the project unfolds.

Another way to think about this is with the concept of measuring a coastline.  This is a well-known mathematical issue (check out a discussion of the paradox here: http://bit.ly/12Hd6S) that posits that the length of a coastline (or the exact amount of effort required to solve a given problem) depends upon the method used to measure it.  The smaller the unit of measure the longer the coastline becomes.  This highlights the fact that the size of a ‘story point’ is relatively arbitrary.  There are two development teams in my firm each using story points and each producing roughly the same amount of work each sprint; one team accomplishes over 140 estimated story points every two weeks and the other team accomplishes roughly 33.  The key I think is finding a consistent method for estimating the effort and complexity of each assigned task on the team; knowing that these estimates will always be approximations and that a team working together over time will improve both its estimation skills and its productivity.

Which raises the next logical question: if story points give us a good way to measure velocity what is the best way to increase it?  Leaving aside for the time being the issue of whether faster is always better (more on that debate in a future post) from my perspective the best way to improve development velocity is by removing impediments.  This again is a core Agile concept and one of the key responsibilities of the Scrum Master (a role often but not always played by the product owner).  Marty Cagan has written a great piece on ten reasons for slow velocity (check it out here: http://bit.ly/10qVtam) and I want to highlight four of them here briefly:

1. User stories are not well defined before the sprint, meaning the team cannot estimate the effort accurately before the sprint and instead spends part of the sprint trying to figure out what work needs to be done.  This impediment can be reduced by a good product owner doing thorough prep work before and between sprints to make sure the product backlog has well-defined items on it.
2. The product and team lack clear vision and focus, leading to ‘churn’ as new ‘top priorities’ emerge every few days.  This is not the same as the valuable ability of Agile teams to pivot when new market intelligence highlights the need to shift a team’s focus.  Instead it is a symptom that the product manager and product owner have not yet grasped the key market need that they are trying to address and are instead using the development team’s work as ‘research’ on what might be valued.
3. Enough time has not been devoted to good design and developer discovery before the coding work begins.  Again, Agile allows for and promotes iterative learning even in the midst of a sprint; but ideally there is some effort put toward exploring potential approaches before the actual development work begins and so the team can more frequently hit the ground running at the start of each sprint.
4. A final impediment to improving velocity comes when the team lacks the right skill set to address the issues prioritized for the sprint.  Making rapid progress toward a good solution becomes quite difficult when the team does not have the right set of people to solve the problem presented.  Here again, basic estimation of the amount and type of effort required before a sprint can help to make sure that the right people are part of a given sprint team.

Once you understand the best way to measure the team’s velocity, and once you have removed the impediments and bottlenecks that inhibit a team’s velocity, then a strong product team just needs good fuel to fire its development pace.  Feeding the team a steady stream of user stories allows it to make gratifying progress at a solid rate over a long period of time.  The successful deployment of functionality valued by the market helps motivate the team to continue developing both quality and quantity.  And avoiding the churn of constantly shifting priorities and requirements allows the development team to function in true partnership with the sales and marketing teams in promoting strong product vision.  Of course teams and individuals have a rhythm, working more efficiently and effectively at some times than at others and sometimes pushing extra hard while at other times catching their breath; I’ll write more about that concept later but a strong team can sustain a solid development pace over the long haul with the understanding that there will certainly be ebbs and flows in the pace of individual sprints.  Can such a development process be both fast and sustainable for the long haul?  The longer answer to that question will have to wait until my next post.  However the short answer is that it depends of course upon how you define those words because, in truth, it’s not that simple.