Tag Archives: process

During quire a few assignments I've been struck by the fact that estimation seems to be done purely out of habit. No-one seems to know what value it brings or if the data collected is ever used. So I've started to question the value of estimation and the way we do it.

This is not to say that estimation is bad and we shouldn't do it. I'm only asking the question of weather the estimation done in many places serves a value and what value is that. I would like to write something about this, based on my observations. However my observations are, by nature, quite limited. I would therefore love to get your feedback on how you do estimation. I would basically like to see if my theories are supported.

I will publish the results and my thoughts and assumptions during the fall. If there is material for it I will also do a talk on the subject.

Please help me out by taking part in this short survey.

Thank You!

I have been at many places, in many teams, where no-one has ownership of the build scripts. It’s an area where a company can bleed a vast amount of time and money without realising it. It  may even be what makes senior member leave in the end due to frustration with to much inaction.

What is unfortunate is that it is relatively simple to fix. Sure, there are risks associated with any legacy clean up. But getting the build to work is far simpler then many other tasks in a legacy codebase. I find that the main reason it is not done is that the team can't communicate the value to management (including product owners). Therefor it gets low priority and ends up at the bottom of the back log.

I have always found that one of the best ways to communicate value to management is in money. By putting forward a business case with a clear RoI (return of investment). When it comes to build scripts this is a pretty easy task. First, ask everyone on the team who uses the build scripts to keep track of how much time they spend doing build related stuff. How much time do they spend working around a broken or non-functional build. Try to count only time which is spent unnecessarily. Once you have enough data to know what the broken builds costs on a weekly/monthly/quarterly (which ever suites your needs) basis it is time to look at how much it will cost to fix the build. I suspect the ratio will be quite scary. The difference is how much you loose each week/month/quarter. Hopefully this should get managements attention and priority.

Now that fixing the build is top in the backlog we need to make sure it doesn't fall back into despair again. This is where ownership comes into play. In a well functioning self organising team this is never an issue. Everyone owns the build. Everyone makes sure the build is just as snappy as everything else.

But If you don't work in senior or self organising team? Who should be responsible? A good place to start is the team. Perhaps someone feels very strongly for it. Passion goes a long way. Granted, you can't have just one who owns the build. It is knowledge which is far to important not to share between at least two. But with one lead it's usually easy to follow. Make sure to pair often to distribute knowledge.

If it's difficult to find someone who wants to take responsibility the team should make sure to pass it around. Share the pain to make it lesser for everyone. The main responsibility will however always fall on the architect. A working build is part of the non functional requirements that makes up an architects main concerns. How will you as the architect be able to guarantee that the solution you are the master builder of will ever reach it's intended user or customer if it cannot be built?

Now, go and fix that build and remove the pain. It is so worth it. And remember, with a working build you'll have so much more time to code, and that is what's really fun!


Technical Debt is something most teams struggle with in one way or other. One of the more common issues I encounter is how to visualise the actual cost of technical debt in a way that the business stakeholders understand. To achieve this I have used a special product backlog type with some additional data.

The debt needs to be tracked in two places. A comment of some kind is needed in the code which will identify and remind the developers that the debt have been logged and is being tracked. I have created a TODO like comment which I’ve called DEBT. The tag holds a link to the backlog item which is tracking the debt. When a developer encounters the comment in the code s/he needs to read the item to understand what and how to deal with the debt.

The second place is the issue tracker for product backlog. The backlog item type needs to keep track of three things:

  • A description.
  • A time guestimate for how long it would take, in man days, to fix this debt. I usually refer to this as the debt.
  • Interest. The interest is calculated in man days spent to circumvent the debt.

When a new technical debt item is created two team members should take part. Two are generally better at both describing something clear and at guestimating how long it will take to pay the debt of. The new debt has to be described in such a way that when someone else encounter the debt in the code s/he understands how this debt is paid of and why it is a debt. Usually the code does a good job of this but not always. A guestimate is required. This defines how big the debt is and is central when evaluating if a debt should be prioritised to be fixed. In my experience guestimates are best made in man days, but if the team is used to doing guestimates in hours that’s OK to as long at the same unit is used when tracking the interest. Once the backlog item have been created a DEBT comment has to be added to the code. The comment should be placed where a developer would typically enter the indebted code. The comment should provide a link to the debt item so anyone can log interest against the debt.

When a team member works with the code and encounters the debt s/he reads the debt item description and logs how much time s/he spends on coding around the debt. In other words how much longer does it take to complete the issue at hand then if the debt would not be present. This amount of time should be added to the interest field in the debt item.

Over time, and if the debt is sever this is usually only a matter of weeks, it will become evident that the team is spending more time paying interest on the loan then what they would spend to pay the debt of. Since both interest and debt is illustrated in the same unit this will become clear to non technical stakeholders just as well.

Further to making technical debt and its costs easy to understand for everyone it will also help to illustrate to the team when a debt should not be paid of. I have many times found my self thinking that a particularly messy part of the code really should be cleaned up and then realising that since it is so rarely touched it is really not worth fixing.

During spring I had the pleasure to work with Brjörn Granvik from Jayway as a mentor in development process. This was a very enlightening experience. I had previously defined a process for the team to work with but it lacked in some areas although no-one was able to pinpoint were the process was failing.

We found it very difficult to control the project and the time line. This had as a nock on effect that we lost credibility with our customer. And every effort we made to improve our estimates failed.

We were creating new functionality that would run on, and integrate to, the worst software I have ever seen (and this is not just my opinion). It would be easy for me to blame all the slips on the difficulty to work with the underlying application code but this would be a cop-out and a lost opportunity to learn from my mistakes.

When Björn came onboard he introduced planning poker as a way to measure the effort required to complete user stories. This is a great aid since it creates a tangible and useful abstraction that is not bound to time. The principles are simple and can be found here

Binding estimates to points rather then time improves the process and controllability of the project. The most striking benefits to me are the following (I will dig into each below):

  • It improves the accuracy of time estimates over the lifetime of the project.
  • It helps manage expectations that the customer has of the project delivery.
  • It empowers the team members and helps create an upward spiral building on success upon success.

When a team start working on a project, or new members join the team, tasks takes longer to complete. When a team have been working steady with a project for a period of time the team will complete the same tasks faster. This is due to what could be regarded as the teams fitness (as in physical fitness). It is therefor waisted effort to estimate tasks in how much time each will take.

First of all, as the team starts the project they will not have any awareness of the level of hidden difficulty in a task. This is only discovered through working with the project.

Second, if the team would accurately estimate the time needed to complete the task for the first couple of months this estimate will no longer be accurate a few month into the project since the teams fitness will have increased by then. Also the technical environment for the project will most likely have changed radically.

Using an effort estimate that is not based on time enables the team to measure project velocity. This is then used to create a time estimate that will, given that the team is kept intact, improve over time. This has serves all three of the above benefits.

Since the projects is not estimated in time the first real estimate of time will happen after the first sprint/iteration of development. This estimate is based on real experience, not guesses. We know that it will change. The next iteration may show that it will take longer. But the next three to four iteration will show that it will be shorter.

The customer is given the initial estimate and knows that this is a worst case estimate. Looking at how SCRUM projects velocity tends to develop the speed will increase.

Since the team is presented with a long timeline where they work through story points in a stead but slow churn it is a wonderful feeling to se this passe increase as each iteration is completed. This empowers the team immensely since it is a feeling of control and and success.

This fall I will again define a process for my team. It's a new team this time and a new company. And there are other needs. But one thing is sure. I will learn from my previous mistakes and I will introduce planning poker as the means to estimate stories.

I listened to a podcast a while back, can't quite remember which, where they were talking to a company that had started with internal blogging. The idea was that all staff got their own blog to write on and were encourage to do so whenever they had an idea or something else they felt could be interesting to share with others in the team, or across the teams. I didn't pay much attention to it at the time though, just though it a bit over the top to be honest. But today it kind of struck me that actually, it's a really good idea.

When everyone is busy with their tasks at hand ever so often someone gets an idea or finds something in their day to day work annoying but at the time there aren't really any forum to communicate this to fellow colleagues so it gets forgotten. Instead this can be captured in a blog post. This will allow for the idea or frustration to be available to others as well as the poster for later when it may come in handy. And as for frustrations in day to day tasks, if enough people find that they share the same frustration this is the point where it's time to do something about it.

So the long and short of it is that it's probably a really good idea to encourage an internal blogging culture in order to identify all the potentially lost opportunities for improvement that disappears in our day to day work.