Velocity is the number of story-points completed during an iteration. It is the most common and natural metric for teams using iterations. Time-over-time, the team can measure its increase (or decrease) in its effectiveness in delivering releasable implementations of requirements. It is powerful and effective within a team.

It is not, however, effective between teams.

Payson Hall, a friend of mine who is in project management consulting, wrote to me recently about a huge system he was reviewing. The project was having difficulty in delivery. The client had paid big bucks for this system and it was about to enter acceptance testing.

To help non-technical people on the project understand what acceptance testing was, my friend explained it was like the final walkthrough of a building before the last check is signed. He said,

Progress in delivering business value needs to be tracked to give feedback to the Business, management, and team. There are many ways to perform tracking. One of the simplest and most transparent is the tracking board. There are many forms of tracking boards. In this blog, I show two common versions: a Kanban board and a Scrum board.

Suppose you have a story such as, "As the customer, I want to be able to opt-out to having my location tracked so that I will not get advertisements specific to where I currently am."

In both Kanban and Scrum, there is an emphasis on developing software in small increments of requirements (stories). However the different approaches to scheduling between iteration-based Scrum and iteration-less Kanban can cause different behaviors to emerge from teams. These behaviors do not exist on all teams, but have been observed on many. One cause is that with iteration-less development, metrics and estimates can impose less overhead for the same net result.

Creating software is about delivering business value. Without some measure of business value, it's hard to determine whether the software has any. For several years, I've presented a session on estimating business value to local user groups and national conferences. My new book, Lean-Agile Acceptance Test-Driven Development: Better Software through Collaboration, includes a section on estimating business value. Here are some ideas from that book and others accumulated over the years.

Dale Emery wrote an excellent article on Writing Maintainable Automated Acceptance Tests. It's at http://dhemery.com/pdf/writing_maintainable_automated_acceptance_tests.pdf. He showed how tfo do the testing in Robot. Bob Martin gave an alternative way to do the tests in Fit at http://blog.objectmentor.com/articles/2009/12/07/writing-maintainable-automated-acceptance-tests.