In No More Iterations I showed our 1^st attempt at a kanban board. Now that we have a little more experience I'd like to show you where we are now and where we stopped on the way.

Here is where we started. Columns for backlog, blocked, in progress and done. Notice the large number of items "in-progress" even though there are only 7 people on the team (can you say multi-tasking?). In fact this was pointing to the fact that developers were building stuff faster than QA could consume it. One bottleneck identified.
	Here is the same board a few weeks later. Note the new column for blocked work in process (WIP) and that the number of in process stories has been reduced significantly. The number of completed stories increased dramatically. We accomplished this by focusing on getting stories done rather than just doing "work". That meant of course that programmers helped out with QA type tasks. It also meant that programmers had time to do some of the environmental cleanup activities that everyone always wants to do, but never has time to do them. Turns out we had time, we were just covering it up with other work An interesting side effect was that developers were not used to having "idle" time and this was very disconcerting for many weeks. It seemed like they were waiting for the other shoe to drop - i.e. some manager was going to come in and yell at them for not working as hard as possible.
This is a task board the team put together to identify the tasks required to complete the stories in the WIP. The idea here was to let other people know what was remaining to be done so that team members could help each other out or at least not step all over each other.
	Here is the next evolution of the task board. The WIP stories are listed down the first column and the various internal states are the remainder of the columns. The sticky notes are the actual tasks that need to get done (color is meaningless).
Here is a combination story task board from a different team. They chose to run the stories across the top row with spots for Backlog, WIP, Blocked and Done. The WIP stories get moved down to head the row just like the other team did. For this team they did use color and sticky dots to indicate various items, but honestly I've forgotten what them meant.

So where are we now? Interestingly things have been going smoothly for awhile so I had to wander over into the team spaces to be sure I remembered correctly. If you've followed along above you may have noticed that the boards got more complicated as we went. Since then we've been simplifying. Also we've gotten used to working this way and it turns out that if you work on a limited number of things, minimize multitasking and talk to each other there isn't much need to use up a big whiteboard with sticky notes.

That's right - we no longer have a kanban board. Now that isn't to say we've abandoned the concepts, we've just determined that we don't need the big visible board.

Currently tasks are being tracked in Extreme Planner and stories are being tracked in a spreadsheet by the project manager.

I use a parallel spreadsheet without all the gory details to help the stakeholder prioritized work, see what is in process and what various releases might look like.

In a way I schedule the entire department on a single 8.5 x 11 piece of paper that has its roots in our very first kanban board.

Throughput and velocity are ways of measuring how fast a team can do work. Knowing how fast a team is going allows the team and their stakeholders to know when something is going to be done.

What is Velocity?

Velocity (http://www.extremeprogramming.org/rules/velocity.html) is a commonly used metric for teams using Extreme Programming or Scrum as their guiding principles for software development. Velocity is a unit-less measure that tells the team how much work they should take on each iteration or sprint.

A simple example of calculating velocity:

At the first sprint planning meeting the team estimates the top 10 stories and believes that they can complete 6 of them in the next 2 weeks based on the following estimates.

Story	Points
A	3
B	5
C	1
D	5
E	2
F	1
Total	17

At the end of 2 weeks stories A-E are complete and F is started, but not complete. This teams velocity is 16 point per iteration, or about 32 points per month. Note there is no credit for partially done work. The next iteration the team estimates stories until they have stories that add up to 16 points. At the end of the iteration they measure what was actually completed and repeat until the project is done.

Velocities cannot be compared across teams because velocity is derived from estimates created by the team and since no team estimates the same way it is impossible to compare them.

Velocity is also not a productivity metric. Wanting to see the velocity have a constant increase is like asking to increase the speed of light. Velocities do vary over time due to various factors (like the fact that software is complex), but tend to stabilize if the work and personnel are not fluctuating too much.

What is Throughput?

Throughput is not commonly used in software development, but is becoming more prevalent with the introduction of lean concepts. Throughput is most common when using a kanban scheduling board (http://blogs.consultantsguild.com/index.php/wayne/2008/02/01/no-more-iterations) to help manage the delivery of stories.

Throughput is the number of things that can be done in a given period of time.

A simple example of calculating throughput:

The team pulls the highest priority item off the backlog and works on it until they are done. They note when they started the story and when they finished it. They do this over and over until the project is over. Every month someone summarized the information about the stories that were completed.

Story	Started	Competed	Duration
A	Jan 1	Jan 4	3
B	Jan 4	Jan 12	8
C	Jan 12	Jan 13	1
D	Jan 13	Jan 25	12
E	Jan 25	Feb 3	9

This team completed 4 stories in January so their throughput is 4 stories per month. Each story takes on average 6 days to complete with a standard deviation of about 5 days. So 90% of stories are completed in 6 days +/- 5 days. With additional data the standard deviation should tighten up unless you have large variance in story size on a regular basis. Even though story E was started in January we don't count it because it was not completed in January. It will go into February's stats.

Since throughput relies on actual start and finish times we can derive a predictive measure for forecasting without any estimating.

Note that duration ignores the fact that some days are weekends.

Like velocity throughput is a team specific number and cannot be compared across teams.

Challenges with Velocity

Velocity is based on an abstract unit such as Story Points (http://en.wikipedia.org/wiki/Story_points) that are not always easy to explain to stakeholders (or even the team sometimes). Stakeholders often want to know how many days a story point represents. Since story points are relative to each other there isn't a direct mapping, although many team do grudgingly come up with an equivalence. To get around this some teams estimate in ideal or engineering hours. Unfortunately the same questions get asked. "How do I convert your funny agile units into days?" See also http://www.think-box.co.uk/blog/2006/02/ideal-time-vs-story-points.html

Velocity also requires the team to spend time estimating the stories. I'm not sure I ever met a developer who enjoyed estimating and even with planning poker (http://en.wikipedia.org wiki/Planning_poker) most team member do what they can to get out of the estimating meeting yielding less than useful results. One team I know of estimated everything as "?" once they got tired.

As in all estimation the results are only as good as the information at hand. When you are estimating something you've never done before the accuracy can be all over the place.

Challenges with Throughput

The big knock against throughput is that it requires you to have relatively similar size stories in your backlog. This is true to a point. If your stories are not of a similar size your standard deviation will be larger leading to a larger range in your completion date predictions.

Which to Use?

In my context (stable teams working on product lines) I prefer the kanban/throughput combination. We don't have the dreaded planning meeting and we are still able to tell our stakeholders how many stories they should plan on having in the next release.

If you are currently using velocity it is very little overhead to start tracking throughput as a way to double check what your velocity metric is telling you.

Cory has a great post titled: Scrum-ban | Lean Software Engineering. In it he describes how a team can take advantage of kanban within a Scrum environment.

While I am sure that there will be those who insist that Scrum doesn't need to be improved, there are those of us who learned Scrum, practiced Scrum and are aware of it's limitations and want our teams to get even better.

Personally I like kanban for the context I work in. When I explain how we develop software I always try to make sure the other person is aware of the context I made my decisions in and how in other contexts I would not make the same decision.

For instance we do not estimate each individual story (although for a short period we did 30 second estimating). We have collected enough data about our performance that we know how many stories per month we complete (~10). Part of this context is a stable team that knows the software and a mature product.

Back in the day I lead contract teams doing work for state and local government. In that context I would go back to estimating because the contracts tended to be fixed price and the team was pulled together just before the project started. Different context, different practices.

I attended AONW last year and had a fabulous time. It was great to reconnect with some of the local practitioners and have some really interesting conversations and be introduced to new idea. If you can make it I would highly recommend attending this year. Remember, attendance is limited to the first 100 people, so sign up soon! Look me up and I'll buy you a frosty beverage of your choice.

Here is a flyer for your office

I mentioned in my No More Iterations post that we didn't really know how support requests were going to affect the overall system. As is often the case I didn't have to wait long to find out.

Within days of moving to the limited WIP approach we got a raft of support requests, several of which turned into "must fix now" types of issues. Since we had just switched, we absolutely didn't have a slot on the board (in fact we had 13 stories for a 6 slot WIP).

Since these urgent requests had to be completed "right now" we decided to go with an "expedited story" concept. An expedited story essentially trumps all other backlog and work in process (WIP) and jumps to the head of the line stomping willy-nilly all over the other in-flight stories.

Obviously we don't want to have a lot of expedited stories so we discussed having a special slot just for expedited stories that would remain empty most of the time, but would also restrict the amount of thrashing the team would experience. However, based on my experience urgent requests tend to come in waves, and telling the business that our process doesn't allow us to help more that one customer at a time is professional suicide. What we are doing is examining all the urgent requests to see if they are truly urgent, or if they could wait a few days. If they can wait we put them on the backlog and process them normally.

To help us understand what is going on over time we are going to track the number of expedited vs. normal stories as well as doing some root cause analysis so we can prevent as many expedited stories as possible in the future.

Travis has a great post on why It's Not OK To Skip The Standup.

In my initial post No More Iterations I mentioned that estimating was a factor in the change we were making. Specifically:

• Story size was difficult to estimate and kept crossing iteration boundaries.
• The programmers really didn't see the value of estimating stuff they weren't familiar with and in our planning poker session gave out lots of ? and 100 cards.
• We were spending to much time researching the time it would take to fix a bug that we weren't going to work on for several weeks.
  

After reading posts by David Anderson and Amit Rathore I started to examine why we were estimating, how much time we were spending at it, the psychic cost, and the results. The results were not encouraging.

Not surprisingly the reason we were estimating was to help the business prioritize stories. If stories X and Y both had the same value to the customer, but story X cost 10x more than story Y (where cost in my world = time) then the business had more information to base their priorities on.

The next question was how much time and effort we were putting into estimates. It turned out that we had two extremes. Either we spent 2-3 minutes estimating a story, or several hours researching a defect (another name for a type of story), but not much in-between.

The psychic cost seemed to be directly related to the time spent estimating. The quick estimating (which used planning poker) often had a background rumble if "I don't really know" which caused some resentment when the estimators had to eventually pick a number. For the more detailed research the task switching had a level of frustration built in, but by far the frustration was that once the detailed estimate was created the work itself was almost complete. Instead they had to task switch back to the planned tasks resulting in more time wasted.

Our results weren't spectacular. The stories seemed to get either 100 points or less than 5. The new unknown work was 100 and the previously researched defects were less than 5. I'm not a big believer in tracking actuals, but it was clear that each 100 point story was not taking about the same amount of time. The defects were typically completed in about the time estimated.

Given this information one could easily conclude that we just needed to do more research so that the new features could be estimated more accurately. But wait a minute, why are we doing estimates in the first place? Are we estimating to create an accurate budget, or to price a bid? In our case we are not. This isn't to say that some people need to do these things, but we don't. Rather we are estimating to provide prioritization information.

I started to wonder if we were trying to be more precise in our estimates than we needed. Enter the concept of t-shirt sizing. Each story could be estimated as a small, medium or large story.

After a few discussion we determined that our smallest stories (mostly defects) really took no less than 3 days from start to finish. So I rounded up to a week and called that a "Small" story. The next boundary to identify was the "Large" story. We decided to call anything that takes more than 1 month a large story. So anything that was between 1 week and 1 month was a "Medium".

I chose the week and month boundaries because they are easy to communicate and part of our everyday language. Remember that the estimates are going to be used by non-technical managers for prioritizing so units like ideal days and gummi bears just get in the way.

Because we now have 3 simple possible outputs from the estimating process I didn't want to spend lots of time coming up with small, medium or large. Accordingly I set the upper limit on research time to 30 seconds. Why 30 seconds? Because for the most part 30 seconds is enough time to develop a gut feel and a gut feel is close enough for the intended use.

I posted a bit of research I did for some externally hosted tools previously. Here is a quick rundown of some self-hosted tools.

• VersionOne Community (free - I've used it and I like it, 5 user limit)
• XPlanner (free OSS, seems good, hasn't been updated since 2006)
• RedMine (free OSS, not really agile, more of an issue tracker like Jira)
• ScrumWorks Basic (free, pro version has more features)
• AgileTrack (new to me, seems to cover the bases - didn't see any burn down charts)
• VersionOne Team (like V1 Community except you get support)
• Project Cards (new to me, seems to cover the bases - didn't see any burn down charts. The UI looks a little MS Access)
• OnTime Express (not agile out of the box, but can be customized to support, similar to
  JIRA+Confluence in that underneath it is an issue tracker and a wiki)
• ExtremePlanner (nice simple system)
• Trichord (more lean than agile, kanban + burndown - interesting)
• OnTime Pro (more features than OnTime Express)
• TargetProcess On-site (new to me, seems similar to V1 and Rally)
• Jira Enterprise (an issue tracking system, but combined with GreenHopper can be very agile)
• VersionOne Enterprise (unlimited users)
• ScrumWorks Pro (more features than Basic)

There are several free options here 2 commercial and 2 OSS. If I only needed 5 users I'd pick V1 otherwise I'd go with XPlanner. There seems to be a sweet spot around $2000. In this range I'd pick either Trichord or ExtremePlanner.

I can't really add anything to Geoff's post. Go read it and apply it.

---

Update: See the list of self hosted agile PM tools

---

I've been researching agile PM tools to decide if we want to continue using our existing tool, switch to another or go 100% manual.

There are a few vendors that provide a hosted service:

• Rally Community (free, but limited to 5 users, a single project and minimal charting)
  
• BaseCamp (not really agile, but widely used)
• VersionOne Team (nice system I've used before and like. The Team version is limited to 5 users)
• Acunote (new to me, seems very complete)
• Jira/Confluence Enterprise (an issue tracking system, but combined with GreenHopper can be very agile)
• ExtremePlanner Live (nice simple system)
• TargetProcess On-demand (new to me, seems similar to V1 and Rally)
• VersionOne Enterprise (unlimited users)
• OnTime Pro (not agile out of the box, but can be customized to support, similar to JIRA+Confluence in that underneath it is an issue tracker and a wiki)
• Rally Enterprise (unlimited users & projects)
• Mingle (seems to cover the bases - agile tracking + wiki, but very expensive)
  
• Wrike (new to me, seems similar to Acunote with lots of support for distributed teams)
  

There are 3 clear groupings for me. Free or nearly free which includes Rally Community, BaseCamp and VersionOne Team. The middle group ranges from $2,400-$3,200. Starting with Extreme Planner Live you are looking at from $7,500-$17,000.

If I had a very small team I would look at Rally Community or V1 Team. For a larger teams I think AcuNote hits the sweet spot. If I had a distributed team Wrike would be worth checking out.

This is not to say that I am refuting our move away from iterations etc. into the "Post Agile" world, rather I am releasing the results of work I did leading up to that decision.