Measuring velocity is not enough to determine team productivity

Introduction

Another interesting question was brought up in a LinkedIn discussion thread: "Is velocity the right approach to measure productivity of team members working in Scrum. If not, then how can productivity of team members be measured in Scrum?" Here are my thought on this topic.

The purpose of velocity

Like burndown charts, velocity is just another metric which the team can use to reach what I believe is the ultimate goal – sustainable throughput. Velocity in my opinion, is not a metric for determining productivity. Productivity or team efficiency is difficult to measure and probably best left for another blog post.

Burndown Charts - It's not about staying below the line

Introduction
I recently participated in a Scrum development discussion thread on Yahoo Groups where one member new to Scrum asked the following: "Our burndown chart's remaining work line always goes up. As a Scrum Master, what do I have to do to make it go down?" This question, surprisingly, generated a lot of response from the community. I found it puzzling to see how adamant some were to introduce solutions to get the remaining work line to go below the estimated work line.

Goal

I believe that the underlying goal should not necessarily be about staying below the estimated time line in a burndown chart (although this would be nice). Rather, the goal should be about achieving SUSTAINABLE THROUGHPUT (figuring out what your team's development capacity is and how much you can shove through the pipeline). A burndown chart is just an information radiator that is there to help you to determine whether that goal of reaching optimal capacity is achieved. That's it. So as a Scrum Master, you should not get too overly hung up on the burndown chart.

Scrum falls short in at least one area in my opinion

Many of us have come to love Scrum, including me. Scrum has been a huge success overall and has turned many a development team around and for the better. Yet in my opinion, I think Scrum falls short in at least one area.

Concept to Cash

Firstly, it's commonly accepted that Scrum does not consider the whole life-cycle i.e. it's a great framework for helping development teams tame the development life cycle but it does not tackle all areas from "concept to cash". Lean and Lean with Kanban certainly appears to be an alternative to Scrum or at least coupled with Scrum to provide and all round concept to cash highly effective framework for producing software products.

NASCAR. Adjustability gets you the winners flag every time

Introduction
Always on the lookout for good analogies to help get my point across, I happened to tune into the Nascar roundup a few weeks ago. Jimmie Johnson was being interviewed about the upcoming event.

As I am sure you can now guess I am a Nascar fan. Most of my friends and colleagues can’t understand this because from the outside looking in, it’s just a bunch of cars going round and round on the same track – what could be more boring than that. Quite the contrary however, Nascar racing is anything but ordinary. It’s a sport that requires incredible concentration, teamwork and most of all careful strategy and agility to outsmart the competition.

It's all about Value, or is it? And if it is all about Value, what is it?

Introduction

In all the scrum literature, there is much rhetoric on focusing on delivering value but there is very little explanation on how you calculate it. Exactly how do you calculate value? I came across an interesting article by Ryan Shriver called "Measurable Value with Agile" where he talks about delivering the right things by choosing tasks based on a cost/benefit analysis, and then delivering those things right with the selected agile method of your choice. Value is then calculated by measuring it via a defined set of identified targets, constraints, and benchmarks. Although I do agree that measuring performance is important, there is still a major problem; if business value can only be measured once a product/feature is delivered, how do you know which user stories to work on first and which ones to avoid? Sure a cost/benefit analysis may be an easy way to determine which tasks to focus on, however, the value of that task is yet to be determined. You can do a cost/benefit analysis, choose the "best" user story based on that analysis, and still deliver a feature that has absolutely zero value. So how do we offset this?

"Stop Starting and Start Finishing" - A successful Lean philosophy

Introduction
One of the killers on software development projects is Work-In-Progress. We have learned from the Lean experts, and from the teachings on the Toyota Production System, that too much work-in-progress is a liability. Just yesterday I was asked to spot the problem with a sister company's task board. Sure enough one developer had 5 or 6 "in-progress" tasks on the task board. It took me a split second to notice.

Productivity
The problem with this situation is that as a developer, if you're working on more than two tasks simultaneously, your productivity takes a dive. Additionally you're going to end up with many unfinished tasks that never gets completed. This is a classic problem in Waterfall where tasks have half-lives are in the order of man months. The more tasks in play at any given time, the more tasks that never get finished.

What makes a good story

Introduction
Leading on from last week where I described that there are two main parts to user stories, the user (or persona or role) and the story (a short description of the intended functionality), this weeks blog is intended to focus on specific details on how to write good stories.

The three C's
Most of you are already aware of the 3 C's i believe originally conceived by Ron Jefferies - Card, Conversation and Confirmation.

User Stories - Tell it like it is

Introduction
At every training session I do on Agile and Scrum, there two questions that are guaranteed to be asked without fail. What are user stories? and Why are they called user stories? Most participants understand that they're some form of user requirement but 99 times out of 100 they confuse user stories with use cases. Requirements are probably the most important aspect of software development. If you get the software requirements wrong, then no matter how good your software development team is, the project is doomed to failure.

The problem
First and foremost, Software requirements is a communications problem. Clients or Customers need to communicate to the development team what they need built. Traditionally, requirements were written up-front and in detail and usually in the form of a requirements document. The problem with this approach however is that requirements are most often frozen or buried in these brutally hard-to-read documents. Not to mention the fact that requirements are often misunderstood due to imperfections in the written language. User stories at their very essence are designed to solve this communications problem and to break down the barriers between the end user and the software development team.

Planning poker - the real epiphany

Intro
Last week I established three good reasons to go with Story Points and why they're so popular. This week I want to talk about one more important aspect of story points and then provide tips on how to get started estimating in Story Points. I find this is a rather big challenge for teams just learning the ropes.

Lets talk
Scrum is a learning framework. It's been designed specifically with Inspect and Adapt points with a very specific purpose. Because estimating is a cross-functional team activity, estimating the backlog is just another opportunity for the team to get together to discuss the task at hand and for the stakeholder or product owner to explain what is expected of the team. This discussion is a great way to build team morale, synchronize expectations and getting everyone singing to the same tune. Because Scrum projects are agile, it’s important that teams engage in discussion to ensure the team stays on the right track. And because the estimation is done in a team setting, the estimate is generally more accurate as it represents a cross functional view of the task size, not just the developer view.