Tag Archives: scrum

Tracking hours worked on a scrum task is counterproductive

Right now I’m reading “Agile Data Warehousing Project Management: Business Intelligence Systems Using Scrum” which I can heartily recommend. This article is about one quote in particular:

Unfortunately, tracking actual hours spent on the individual tasks is ineffective, aims at the wrong objectives, and drowns the developers in detail while undermining agile’s pillar of self-organization that is so crucial to a team’s velocity. Tracking actuals should be strongly discouraged.

I would go one step further and say tracking actuals can end up having a negative effect on your scrum project. Before I get into why its worth pointing out that for short periods of time it can be useful particularly if you need to gather data on where you are spending your time (see the second point below). Once you have the data though – stop recording.

So why is tracking actuals so counterproductive? Primarily because it subverts the iterative estimation method.

One of the key activities in a scrum process is to update the remaining time estimate every day. From this estimate a burn down is calculated and the burn down is then used to monitor and adjust the sprint in order to deliver.

Consider what happens when scrum team members are logging the amount of time they worked on a task. Simple maths tells the remaining time is the current estimate minus the hours worked so there is a temptation to skip the re-estimating step. As a result a sprint burns down at a constant rate (ignoring task completion as a backup progress indicator) and inevitably it is not until the end of the sprint that underestimation is discovered; too late to do anything about it.

This second point can be good or bad depending on management and team culture – if you log time correctly and in detail you will know where you are spending time including interruptions, meetings, etc. There are two types of response from the team:

  1. Look at all this waste activity we are doing – how can we remove it and spend more time on value add work?
  2. How can I possibly deliver on my sprint commitments – look at the other work I had to do during the sprint.

Obviously you want the first response.

Finally, overshooting sprints is something to be avoided but often there are additional constraints on time logging that cause you to miss estimate future sprints as well. I know of many organisations where team members are required to log a fixed number of hours a day; no more, no less. You can imagine the havoc this causes – if you work 5 or 15 hours during one day on a task but have to log 8 then you create an inaccurate data set from which to base future sprint planning on.


Show and Tell

Tomorrow is “Show and Tell” day. This is our take on the Scrum Sprint Review where the idea is to show the team’s progress and direction to the Chickens. The review is open to anyone who would like to come and see what the engineers have been up to for the last month. The format is fairly loose – as all the developers have laptops they can take turns to plug into a projector and show what they’ve been up to. Individual presentations are limited to 15 minutes + question time.

The benefits are obvious: engineers get a chance to show off their work and direct feedback from the people who are dependent on their creations; Sales, marketing and management get to review progress and provide input.

There is always a little nervousness on my part because I don’t do much speaking – it’s up to the individual developers. Their view of the world revolves around code, architecture and designs whereas the chickens think about schedules, customers and revenue. With the two positions, there is some room for difference of opinion but regular reviews keep everyone on the same page.

So roll on the demos…

Sprint Review Time

It’s nearly the end of the month and hence end of the current sprint. I was having a discussion with a developer this morning about the amount of work remaining on the list. The developer in question hasn’t been able to spend a lot of time on the project this month due to higher priority customer needs and therefore won’t be able to complete his agreed functionality.

According to Scrum, we have two seemingly opposing forces:

  1. The end of sprint review where the team shows the progress for the sprint
  2. The rule that “only potentially shippable code” should be shown

The problem is that his part of the system is the user interface and without it the sprint review will be mostly white-board and some of NUnit tests. Not very exciting and not liable to provoke much discussion. So he asked the question – “Should I just hack it to get something on-screen”? I had to think about this for a while because it’s very tempting to say yes. I could almost justify it by saying that its demo code and will be thrown away.
After, musing for a couple of minutes I said no for the following reasons:

  1. Rule (2) above
  2. The sprint review is designed to show project progress and demo code is not progress
  3. The act of hacking in demo code and pulling it out again tends to add entropy and hence bugs into the system

So a question for a future post should be “Why did I not clear the block (customer needs) for the developer?”.