Question #5

SCRUM talks about “sprints”. How about carrying the analogy forward and awarding ribbons at the end of each sprint. Blue if the target was achieved, Red if the target met 95% of expectations, etc. The point is that the set of ribbons that a team receives overtime become their scorecard of achievement. It is management’s job to ensure that they are successful (remove barriers, provide training, etc.) It also makes the team accountable to achieve results.

Agile tends to look at the completion of stories (or usecases or features or units of work) as a binary event. When the story is written, an acceptance criteria is defined that meets both the Verification requirements and the Validation requirements. This being said, during a sprint - or as it is more generally called, an iteration – things can be marked as done only if both QA and the Business agree that Verification and Validation have been satisfied.

At the beginning of the iteration, the team committed to completing a certain number of items. The burndown charts how they are doing and allows both the project team and outside observers to wonder out loud whether they are going to be able to meet their commitment or not and if not, what they can do to help facilitate meeting it. It begins giving you leading indication immediately and sponsors such conversations much earlier than with other methodologies.

Additionally, there is another graph called a burnup that tracks the teams progress against its release target. The two charts have to be used in concert to truly help control the project, as the team uses only the burndown, they can continually adjust the level of their commitment to the point where they are not really taking on much if any new work; however they are indeed meeting it each iteration and winning kudos from their management. In this situation, the Projected Release dates looms large only to find that most of the work is not done. By trending the number of stories “completed” after each iteration against the goal set during the project’s chartering process, the organization gets a much better picture of the actual productivity of the team.

There is another derived metric that has much controversy about it in the agile community and it is Velocity. I use velocity as the effectiveness of the team on the project. This is a fine distinction and needs to be made. People do a lot of stuff at work, most of which is important to the business at some level, even if it is otherwise classified as overhead. We encourage teams to not multi-task so that we can eliminate costly context switching times, but sometime it has to happen. Therefore, when we look at velocity, we are looking at the effectiveness of the team on this project. Low velocities are always cause for investigation and discussion, but it MUST be remembered that low velocity is often not the fault of the individuals, but rather the environment they have been cast into to execute the project.

Now, if you have the team estimate their work in a unit called Ideal Hours, then you can create a ratio between Ideal Hours and Actual Hours (duration), which gives you a measure of the effectiveness of the team. Ideal Hours are uninterrupted hours an individual or team can work on a task. Uninterrupted means no phone calls, no IMs, no email, no meetings, nothing that is not directly associated to the task at hand. When we train this, we talk about coming into work on the Saturday they were doing the upgrade to the Exchange Server and the PBX at the same time, so you got to sit in front of your workstation completely uninterrupted and hyper-focus, getting done far faster than you imagined possible….. This is the same concept that TOC/CCPM refers to a aggressive but possible estimates, or estimating at the 50th percentile for probability of completion. There is indeed an entire art to estimating, and the agile approach incorporates many approaches that actually produce a far better over estimate than any other methodology – we can talk about those separately.

Once you have the estimates in the Ideal Hours, the ratio is developed against durational hours of the team (these are all team measures) where you compile the total number of hours available to the team minus their preplanned vacation, training, or other non-work commitments. The Velocity measure is usually, for a highly functioning team, between 25% and 45% depending upon its size and whether or not it is distributed (collocation increases velocity). Velocity is also a function of the complexity of the project and the degree innovation plays in the ultimate results, so you would expect a highly distributed project with a high degree of technical difficulty and a fair amount of innovation to have a much lower velocity than a legacy conversion. The skilled coach or management team will understand these factors from the project’s charter and will acknowledge it, but the real value is as a base line factor. If the team varies substantially from expected velocity values, the work is potentially more complex than they thought or they are deviating from the desired expectations from the business, or everything is fine and great things are happening – regardless, a question should be surfaced and answered.

So, back to your point. All of that is correct. You do need to know what you are actually measuring though, before you start rewarding. But the ribbon idea is great - a blue ribbon sprint as versus a red ribbon sprint!