A practical guide for dealing with capacikill in TFS

Capacikill? What the … is that?

Actually it is a word I made up. To be honest it was a colleague who talked about capacity in a noisy room and I thought I heard him say it. I understood capacikill and the word had a meaning to me right away. As you can obviously see, it is a merge of the words capacity and kill but what do I mean by it?

This blog post is about giving meaning to this word to others besides me.

Scrum vs. Capacity planning

When doing Scrum in its purest form, capacity is the easiest thing to manage. There is a Scrum team consisting of a number of people. These people work full-time on sprint work. Capacity is simple. (Number of people in Scrum Team) x (Number of Days in Sprint) x (Number of Hours per Day)

The team maintains remaining work and this reflects in the burndown. Piece of cake!

If you like, Team Foundation Server can do a fairly good job in managing the capacity for this scenario. The sprint backlog has a capacity tab which allows you to maintain capacity and easily track under- or over estimation. By filling in the capacity per Team Member and optionally adding an [activity] to a team member, TFS nicely creates some graphs for you based on the [Remaining work] per [Task].

Back to real life, back to capacikill

Unfortunately many companies, at least most of my customers, do not have the luxury to have full dedicated Scrum teams that spent their time solely on sprint. Many customers have to deal with what I call capacikill. The constant battle for capacity and resources and eventually the choice between spending time on the sprint or on other (most of the time unavoidable) work. This is not the worst part of it. The biggest issue is, how do we manage this ?

The most common reasons for capacikill I see are:

Unplanned work during a sprint

Team members are needed by another team, help out their manager, write something for the website etc. etc. Many people in a team get unplanned tasks unrelated to the sprint. Talk to the Product Owner might help sometimes in dodging the tasks but usually it is just something people have to deal with.

Bugfixing / Hotfixes for production or acceptance

Some companies (I am sure this does not apply to you 😉 ) do hotfixes on their production software. Once the product has been released, a critical bug pops up and this has to be fixed no matter what. If you are lucky this is sporadically and only with mission critical bugs on production. If you are less lucky this also happens for not so critical bugs on production and even acceptance.

Analysis / refinement work for next sprints
When doing Scrum you do not have design up-front. This leads to waste. Waste leads to anger and anger leads to the dark side. However, on many occasions (especially with large and complex) systems, some design is needed up front. In Scrum this is covered by refinement sessions but sometimes this is not enough. Sometimes people are needed to dive into a problem. And sometimes it is hard to say for which User Story this is or how long it will take

All these reasons have two things in common. The work cannot be planned during Sprint Planning and the work done is at the expense of Sprint work.

Managing capacikill

The question I get a lot is: “How do we know where our time is spent?” At the end of the sprint we have a lot of undone work but we do not exactly know why this is?

Agile purists will say that you have the burndown that will show this and that the Daily Stand-up will cover the reasons and I agree with them. But after a week or two the question is harder to answer and human memory is not the most reliable instrument.

To deal with the “unplanned” work without interfering with the Scrum way of working in TFS I tend to keep things as simple as possible. Bring all of the work inside the sprint and visualize it accordingly. Let me explain with a simple picture.

When you do not bring the unplanned work inside the sprint, you might have to do separate administration. The big question is where?

The solution is to treat unplanned work as “in sprint” work. By doing this everything is visible on the Scrum board and in the burndown. The biggest advantage is that everybody knows how to deal with unplanned work because it is always in the same way.

I see many examples where bugs has to be administered in one way, and unplanned work in another way.

Another big advantage is that you don’t have to deal with changing the capacity all the time.

Sure, it disturbs the burndown a bit with “unreal” work but the burndown should merely be a signal for the team to see things are getting out of band.

Using TFS

I start with capacity. This is easy. I look at the available hours per person, register the days off (if applicable) and subtract the scrum ceremony time (Sprint planning, review, retrospective etc.). This is usually always the same.

Then after sprint planning I create a Product Backlog Item in the sprint called “Unplanned”. Every time unplanned work comes up, people create a task and register the estimated remaining work. This automatically reflects in the burndown as it should!

For Bugfixes I create another PBI and create a task in the same manner. Optionally you can link the task to the Bug. I usually do not put hotfix bugs within the sprint.

Summary

Capacikill is something that happens. Resources are not limited to a sprint on many occasions. In order to deal with it you can either set up a separate administration or administer it the way you are used to.

By putting the “unplanned” work into your sprint and using placeholder PBI’s and tasks you can easily manage your capacity and still have all the benefits of your agile boards.