Many Scrum teams use two levels of estimation: A relative estimation technique like Story Points for estimating features, and hourly estimates for tasks.

I’m often asked how such a system can be implemented in Tools For Agile.

Well, we have a plugin for that! Starting May 2012, this plugin is enabled by default, but if you created the board earlier then will have to enable the plugin manually.

To enable the plugin,

• Go to the Board Settings page and click to the Plugins section
• Enabled the Two Level Estimation plugin if it is not enabled already

Once the plugin is enabled, you’ll get a Story Points field when creating a card.

And on the card, the story point will be displayed with a little star icon next to the number.

When the plugin is enabled, the following metrics will use the Story Point value in the calculation:

• Average velocity
• Scheduled velocity
• Project burndown graph
• Velocity trend graph

Note that the iteration burndown will still use the task estimate values.

Today’s release allows board owners to customise the properties shown on the card.

When you create a custom field, you can now choose whether the property value should be shown on the card in the board, the card in the backlog or not shown at all.

With this update, the you can customise the visualisation to show you the important properties you need for prioritising, or for execution when the card is on the board, or hide properties that contain information that you don’t want to visualise on the card (you can still see the full card property values in the card details page).

A question came up in a recent discussion about why agile teams need to understand basic statistics.

Here is why…

[Note: the following post talks about Scrum teams and velocity. The equivalent for Kanban teams is lead time, so replace velocity with lead time everywhere if you are doing Kanban]

Take an example of a scrum team that committed to 40 points, delivered 20, then had a fiery debate during the retrospective about what went wrong and how to prevent it next time.

The next sprint they make some changes, deliver 45 points, get excited about the impact of their changes and decide that they should aim for 50 points now.

The sprint after they deliver only 30 points. Disaster!! Its doom and gloom at the retrospective about what went wrong this time. The Scrum Master steps in and says that its a major regression, this cant continue. That’s two sprints where they missed commitments by 20 points and stakeholders aren’t impressed. He recommends that they should seriously consider working weekends to hit commitments made to the stakeholders…..

How many times have we seen this pattern? Without realising it, this team is doing the absolutely worst thing possible. It’s called tampering. What is tampering? Read on…

Tampering

Lets change the context.

Assume that you are driving to work everyday. It takes you 30 minutes to get there. Now, that does not mean it takes you exactly 30 minutes every day. Some days it might be 25 minutes, other days it might take 35 minutes, but on average you know its somewhere around 30.

In fact, if you were to plot your times every day for forty days, it might look something like this (the Y-axis represents how many minutes early or late you arrive at work each day)

Most people would not raise an eyebrow at this graph. It is quite natural that the driving time varies each day. The cause for the variation could be anything — difference in traffic levels, how many red lights you hit etc.

But now you decide to get a little clever. You decide to look at yesterday’s time and use that to change your behaviour the following day.

The first day you reach office in 25 minutes. So the next day you think, “yesterday it took just 25 minutes, so I can leave 5 minutes late today”. Unfortunately, today it takes 35 minutes. Add your 5 minute lateness in starting out, and you reach office 10 minutes late. The day after you are cautious. You reached 10 minutes late yesterday, so today you leave 10 minutes early. This time it takes the usual 30 minutes, and you reach office 10 minutes early (because you started 10 minutes early).

In fact, if you followed this strategy, then with the same sequence of driving times above, this is what your result would be

With this clever new strategy, the graph swings wildly. Some days you are as much as 30 minutes early. Other days 30 minutes late.

Lets recap…

If you just blindly leave home 30 minutes before time everyday, you’ll reach between 10 minutes early and 10 minutes late each day. This is a stable system.

If you look at yesterday’s time and try to compensate the next day, the variation increases. After a few days of following this strategy, you’ll be arriving way too early or late. This system is out of control.

This is called tampering – Meddling with the system when you should leave it alone.

Or as Dr.Deming said, “Dont just do something, stand there“.

Understanding Variation

Everything has variation. Some things have less variation, others have more, but everything has variation. The variation inherent in the system is called Common Cause variation. In the driving example, the traffic pattern changes slightly, your luck with the signals change.. all this causes a variation in the time you take to reach office.

Another type of variation is called Special Cause variation. Special cause variation has an assignable cause that you can point to that caused the variation. For example, if there is an accident, or a diversion on the road — the delay due to that is special cause variation.

For special cause variation, you can point to a particular point and ask “who or what caused this?”. You can do a root cause analysis to find and eliminate the problem.

An agile team also has variation in how they work. Some days you work well, other days things don’t go so great. This is just normal day to day stuff which happens, and it causes variation. One sprint they do 40 points, the next sprint they do 20 points. The sprint after, they might do more than 40 points. Thats pretty normal, and its usually cause by common cause variation. Sometime you have special cause variation, eg: If a sprint spans the Christmas + New Year week, then the loss in velocity is a special cause.

Tampering revisited

The problem arises when we confuse common cause variation for special cause, and try to find an assignable cause in a common cause variation and attempt to “fix it”.

When the velocity drops from 40 points last sprint to 20 points this sprint, then teams typically look at figuring out why that happened. The problem is, nothing might have happened. It could have just been the usual routine variation in the system. In that case, any “fixes” that are applied may end up tampering the system. The next sprint, the velocity changes again due to routine variation (plus any side effects from the “fix”). Teams then scramble to figure out what happened this time.

The result is a system that goes out of control.

The only two ways to hit a constant velocity

Everyone says that agile teams should have a constant velocity. There are only two ways to do this:

1. Be an insanely amazing team that has absolutely no variation at all
2. Game the numbers [Slow down when you are ahead, and work overtime when you are behind]

There are probably a handful of teams (I might even go on a limb and say there are none) that can produce perfectly consistently without any variation whatsoever.

That means if you’re velocity is constant, you’re gaming it. Worse, it probably means you are working overtime to get there. And once you hit the number, you’re going to be working overtime most of the other sprints in order to keep your velocity there.

The difference between tampering and process improvement

Some of you might ask, “what about process improvement? Isn’t that tampering?”. No, its not. Tampering is looking at one data point which does not have any special variation, drawing conclusions from it, and attempting to fix the system based on it. Process improvement looks at a much longer period of time to draw conclusions from.

Yesterday’s weather is a bad way to plan and as we saw in the graph above, it can lead to severe problems.

Some teams use the average of the last five sprints, which is a better approach. You did 40 points this sprint? Great, now plan for 30 points next sprint. You did 20 points? Thats okay, plan for 30 points again.

Also, don’t mistake variation for improvement. So you did 30 points the last sprint, and did 40 points this sprint? Hold the celebrations. How do you know that this is improvement and not just usual variation?

Answer: You don’t. Two points don’t make a trend. Only recalibrate your forecast after delivering more than planned for 4-5 sprints in a row.

Even better, don’t use target sprint commitment. Let the team do however much they can, and deliver whatever was completed.

We just made a new release that takes card customisation to the next level.

Until today, we provided six predefined card types and colours – Feature, Bug, Support, Enhancement, Spike and Chore. These card types were associated with six coloured cards. You could use these six colours, but you couldn’t create your own card types. Also, custom fields that were rendered on the card had their colours auto-generated, and you couldn’t pick their colours.

You can now do both

Define new card types

With today’s release, you can define your own card types and select the colours you want for them. This allows you to create many more types than the standard ones in use in development teams.

But that is not all. You can now select colours for any custom fields. When the field value is displayed on the card, we take the colour that if you defined. If you haven’t defined anything, then we  auto-generate the colour as before. So what good is it to select colours for field values? Well, perhaps some options are important and you want to highlight them so that they draw the eye towards them.

Here are some examples of a few ways to use custom card types.

Example: A Portfolio Board

The example below shows a high level portfolio board with a number of initiatives. Each initiative is a card of a particular type — Differentiators, Table Stakes and Long Term Investments. By creating three new types of cards with different colours for each of these initiative types, we can easily see the distribution of initiatives that are “in flight”.

Example: An Integrated Risk Board

This example shows a usual board, with an additional risk tracking section to the right. The cards in this section are custom defined “risk” type cards with a yellow colour.

Example: Pinning notes to the board

Not every card type has to be something that has to be worked on or tracked. How about creating a type just for easy visualisation? The board below has cards with a custom “notes” type in blue. These notes are placed in one column and are purely there to write notes and make them visible on the board, just like you would with sticky notes.

One of the great things about a physical board is that its always big and visible. Anyone working in the room, or even walking through it, will glance at it once in a while.  Because of the huge amount of bandwidth our brain dedicates to decoding visual patterns, a glance is all one needs to quickly figure out the state of the work.

Unfortunately, when a team migrates to an electronic board, the big visible chart is gone. This is not a good thing, because now everyone has to log into the tool to see the board. You aren’t going to be doing that in the middle of your work, or while walking through the room.

Luckily, there are ways to solve this.

Here are five ways to make your electronic board more visible

1. Get a projector: Find some blank wall space, get a projector and project the board on the wall. As an added bonus, you can probably project it much bigger than even a physical board.
2. Get a large monitor: Sometimes you don’t have a big empty wall available. Hook up the electronic board display to a large monitor and have it display the board at all times.
3. Get a touchscreen monitor: Even better, get a touch screen monitor. Then you’ll be able to drag and drop cards with your finger
4. Go small: The opposite of one big visible radiator is to have many small radiators. With a physical board, you are restricted to one board which has to be in the team room. No such restriction with electronic boards! A huge advantage of electronic boards is that you can create as many copies as you want. How about having many small monitors (maybe even iPads/tablets?) at multiple places through the team room, so that everyone can view and interact with the board from different places in the room.
5. Go far: Taking the multiple display solution one step further, ho about putting a small monitor at the entrance of your team room, another small one by the water cooler or cafeteria and one more in the board room. Imagine strolling by the water cooler and being able to see different boards from all the various teams who work on that floor.

All this (especially 4 & 5) is very exciting, because it allows you to bring in a whole lot more visibility than was ever possible with a physical board.

Of course, there is one thing that is required to do this: Synchronisation between multiple displays of a board. When someone updates a board, you don’t want all the other displays to be showing stale information.

Manually hitting refresh every minute is out of the question, and reloading the whole page every few seconds is slow, and resource intensive. Automatically reloading the page at a less frequent interval (say every few minutes) means that the radiators are showing stale information on busy boards.

The ideal situation is to have real time board synchronisation in the electronic tool. With real time sync, a whole lot of exciting possibilities just open up.

Over the last few months, we’ve built up our application architecture to support real time communication. We are extremely happy to  announce our first feature built on this architecture – real time board synchronisation.

With real time synchronisation, if one person makes a change on the board (moves a card for example), then that change is automatically propagated to all others who are viewing the board which are in turn updated in real time. Perfect for distributed team collaboration. It’s a lot of fun to project the board on the wall and watch the cards move by themselves as team members update the board

Here is a video showing real time synchroniation in action:

[If you are reading this in an RSS reader or email, then click here to view the video]

Jim Coplein posted on Jeff Sutherland’s blog basically criticising Kanban and trying to put forward a case of why Scrum is closer to Toyota’s principles that Kanban.

I’m not going to comment on the post (not directly anyway), but here is a story:

Five years ago I posted about a trend that was happening then, of asking whether a practice is agile or not. There would be endless debates about whether doing Practice X was big design up front (BDUF) or whether it violated YAGNI and what have you. Sometimes you would come across a post where a person loved a technique, but was afraid that it was big design up front. Just to set the context, in those days XP was the dominant method in the agile space and BDUF and YAGNI were the hot topics of discussion. The bone of contention was with methods like FDD that promoted up-front modeling, and Crystal which encouraged documentation and up-front UX design, and DSDM which many XP thought leaders found to be too heavy.

People essentially stopped asking “is it useful?” and started asking “is it agile?”

As any community forms around an idea, the first few years are open to playing around with it and improving it, but after a point the community attention switches over to protecting the idea from corruption and external forces. This protects the initial idea, but closes it down to growth. A lot of good ideas get discarded, because “it isn’t agile”.

I’ve learnt a lot of good things from reading FDD, and Crystal, and talking to people about CMMI. Its funny how many people in the agile community are happy to bash CMMI without ever talking to someone accomplished in it. To be frank, I was in that camp too, until I had a number of discussions with people who understood CMMI well. It turns out that CMMI has a lot of interesting ideas.

Today, people dont talk too much about XP anymore. Most of the XP thought leaders have moved on, some to the Scrum or Kanban world, others elsewhere. Meanwhile a lot of XP has been absorbed as standard practices that teams pick and choose for their project. Teams no longer talk about “doing XP” (as a package) but more about we’re doing TDD or we’re doing continuous integration.

But history repeats itself, and once again we find the question coming around once again to “is it agile?” instead of “is it useful?”

PS: Agile India 2012 is coming up next year. Be prepared to discuss a number of interesting topics, some of which might fail the “is it agile?” test Registrations are open, so what are you waiting for?

Did you know that you could link code commits in your source control system to cards in Tools For Agile?

If you didn’t, then take a look at the video below to see you can integrate with subversion. (You can find detailed instructions here)

The integration looks at the commit message for the card #id and links the card in Tools for Agile to the commit. You can then look at the card details page to see a list of all commits that are linked to that card.

[If you are reading this in an RSS reader or email, then click here to see the video]

Following up on a twitter discussion, Pawel blogged about alternative kanban board designs, and showed an interesting board with columns indicating priority and stickies on a card to indicate the tasks to complete. This motivated me to search for pictures of the board we used back when we first adopted agile process. Pawel says that exposure to “standard kanban boards” has meant that everyone has ended up with similar looking boards. I think to an extent that is true. This board was designed in 2005, much before there was a kanban method, and it doesn’t really look like a kanban board you would see today. In fact, I wouldn’t even call it a kanban board as it has no WIP limits or pull. It’s more of a team board visualisation.

Early 2005

This is the board from early 2005.

The board has three sections

1. Not Started. The cards that are not started are arranged in columns, based on who is planning to pick up that card (although it could eventually be picked by someone else)
2. In Progress. Cards in progress are arranged in columns, each column containing cards of one team member
3. Awaiting verification. This column in labeled “Customer”. These are cards that are complete and are awaiting verification. Usually the verification was done by me.

The colour of the card indicated the type: Pink for important work, orange for bugs, yellow for new features and green for enhancements.

A couple of patterns jump out straight away:

First, most of the cards are waiting on the customer. That’s because the customer (me) only verified cards at the end of the release. We did three week releases, so these cards would queue up for three weeks. If any card wasn’t okay, then we would put it back into the Not Started section for the next release.

Second, look at the amount of multitasking for some team members relative to others. Some team members are overloaded for sure.

July 2005

This photograph was taken sometime in July 2005, so its a few months later.

You can see that there are two boards now. The board on the left, directly facing the camera is the roadmap board. This board contains the “big features” that were planned for the next six releases. You can see the release number and date on the top card of each column. The team board on the right has also been redone. Team names have been replaced by photographs, but more significantly you can see that the multitasking is way down. Also the customer column, while still long, is now a lot shorter compared to before as some cards were verified without waiting for the release date. It also helped that we could cards which failed verification back and fix it before the release came.

Visualisation is the important part

Day before yesterday I blogged that visualisation is the key to being agile. You can see that in action here. After putting up the team board, suddenly every team member knew what was going on. This enabled the team to take ownership of the work, leading to better collaboration, and better agility. Nothing rocket science about this. The success of the team board prompted us to create the roadmap board with the next six releases on it.

More patterns

The team board is just one of many kanban board pattern. Pawel’s blog post shows another pattern. At LSSC12 Alisson Vale showed me a board where the team board pattern is embedded within a larger kanban board (You can see that board depicted in our electronic kanban board tool here). Visualisation goes far, far beyond just the basic kanban board.  If you are interested in visualisation, then check the recording of my July webinar on Advanced Kanban Board Patterns.

Also, visualisation isn’t just for a team’s work items. You can see above that the visualisation of the roadmap that we did in 2005. It was rather basic and didn’t visualise everything we wanted. So I was always on the lookout for a better way to go about it. In the last three years, I’ve become a big fan of using story mapping as a way to visualise a project vision, roadmap and progress against that vision. If you’re interested in story maps from a visualisation standpoint, then sign up for my upcoming webinar this month on story mapping.

This coming weekend, I’m going to be talking at Agile Tour Chennai about visualisation in the context of agile teams.

It is my belief the visualisation is the key to being truly agile. Why? Read on..

Imagine for a moment that you’re playing a sport. Lets say football (soccer). Also imagine that the players in your team are told to wear blinkers (blinkers are what they put on horses so they can see only ahead), giving them a limited vision range, maybe just 1 metre in front of them. Only the coach can see the whole field. Therefore the coach has to tell the players where to kick the ball, and the players blindly follow the coach’s orders. How effective do you think this football team is going to be?

Donald Gray has a fabulous case study about three different leadership styles brought out while managing traffic at an intersection. This is a fantastic article and I suggest everyone read it and come back here. He shows how a policeman manually trying to manage the traffic is a lot less effective compared to leaving the drivers to figure it out themselves. Anyone who has driven in India knows this already. The traffic here is utter chaos, but it flows, even when the traffic lights aren’t working. In fact, if you see a long jam, chances are high that policemen are manually regulating the traffic!!

What these stories tell us is that when lots of complex decisions are to be taken, it is a better to decentralise decision making lower in the system.

Lets rewind back to the football team. Anybody can figure out that playing the team with blinkers, and the coach directing every move is a bad idea. It’s so obvious that you wouldn’t even consider it for a single moment. But, isn’t that exactly what we are doing in our software development teams? The project manager is often the only one who knows whats going on in the bigger picture. The team is developing with blinkers on. The project manager makes the move, communicates it to the team and the team executes the move. It’s not a very effective way of working.

In fact, like the policemen story, a single project manager who makes decisions on behalf of the team is likely to only make things worse. A project manager who assigns tasks to people in an attempt to balance work, is more likely to overload some people compared to each person picking up a task themselves when as they get free.

#1 A team is more effective when they make team level decisions for themselves.

But of course, thats not enough. If the blinkers are on, the team is going to flounder. You cant expect a team to make decisions effectively when they can only see a limited view. So you need to remove the blinkers. They have to see the same picture that the project manager sees when making a decision. They need to know what everyone is working on, and whats stage each work is in, and what is upcoming.

#2 Make the work visible.

Making work visible is good, but humans find it hard to make out patterns (unless its really obvious) from a table or spreadsheet. In this amazing TED video, David McCandless explains how the visual bandwidth of the  human brain far exceeds any other sense. Analytic capabilities are tiny by comparison. We are genetically predisposed to being very fast at identifying colour, shape, pattern and geometries.

Here is an example: Take 10 seconds (no cheating! ) looking at this, and see what you notice

Did you notice these things:

1. Everything going to Test is being blocked
2. Lots of things in progress, nothing completed
3. Sid is overloaded with work and is multitasking many stories

How does this team move forward? Take a while to think about possible next actions, before heading to the next section.

Now take 10 seconds looking at this:

Find it easier to see the patterns?

Now, how does this team move forward?

• It would seem that the first step is to unblock test and get those cards to completion. No point finishing Development cards and adding it to a blocked test queue. So the developers drop what they are working on, and pair with the Ram & Arjun to fix the bugs and get those cards passed
• Then Ram & Arjun (now free) help Sid to cut down the multitasking and get get some of the cards through test
• The bottleneck at test and development are now both untangled. The team discusses how the queue got blocked, how Sid landed up with three cards in progress, and how it can be avoided

Go back to the spreadsheet. Did any of these steps jump out? Come back to the visualisation. Did these steps jump out?

These are the kinds of decisions that team members can take for themselves when the blinkers are off. Much better than the project manager trying to make the decisions.

#3 Visualise the work

Visualisation leads to understanding. Understanding enables team decision making. Team decision making enables collaboration and agility.

Some of our case studies back this up. When teams could visualise work, they collaborate more, and self organise better, leading to better agility.

The best part?

Project managers get to take a break from all that decision making and can focus on much higher value activities, like steering the team towards the goal.