When I was much younger, it was explained to me that sticking my dad’s screwdriver into the electrical outlet was not a good idea. As a good little boy, I obeyed and convinced my older brother to try it, instead. Fortunately, we used an outlet at the end of a long hallway, so my brother’s resulting flight from the shock drew a clean and uninterrupted arc down the hallway.

For those of you now considering how heartless I was as a child, rest assured that Karma got me back a number of years later when I mis-used a microtester while checking a 220-volt power line.
Whether I used the screwdriver or multitester wrong, there was nothing that the tools themselves could do to keep me from using them incorrectly, nor would the tools do anything to fix what I had done. Similarly, the tools we use in software development cannot stop us from making poor decisions and they usually can’t clean up the mess that ensues. Even though we would like them to be, tools aren’t a cure for the poison of bad decisions.

Until the 17th century, it was widely believed that the unicorn horn cured almost anything. From being an antidote to poisons of all sorts, from the plague to epilepsy, the unicorn horn was priceless. The Church of St. Denis in Paris frequently used its unicorn horn by dipping it in water to create a restorative elixir drunk by the infirm. Similarly, there are many times when we would wish our software tools could miraculously fix whatever is poisoning our projects.

I’ve seen instances in which Sprint lengths were shorter some Sprints, but longer for others. When a software tool written to follow the concepts of Scrum can’t properly represent the project burndown because of the varied Sprint lengths, it raises concern that the tool won’t normalize the sprint lengths to provide a simpler view. In my opinion, however, the question shouldn’t be why the tool doesn’t support Sprints of varying lengths. The proper question is: Why does the organization use Sprints of varying lengths? The issue of Sprint length has been debated in various forums and, while we all have different opinions about how long a Sprint should be (a recent sampling suggested three weeks was the most popular), we mostly agree that Sprint length, whatever we choose, should remain consistent. Rather than use a tool as a panacea to mask the problem, one course of action is to scrutinize the forces that drive Sprint length in the organization. Are large stories extending Sprint length? Is management forcing shorter Sprints? Why? Remember, the tool isn’t supposed to fix organizational issues like this. In fact, when the tool doesn’t support what the organization is doing, questions should be asked about organizational decisions.

Another situation I see frequently are teams that rarely reach their Sprint Review meetings with all of the committed goals completed. Strangely, many tools don’t accurately reflect a team’s real progress, presenting a relatively normal burn when a team’s stories aren’t actually done. So why doesn’t the tool show what’s obviously happening to the team? How good is the tool if it can’t even show when a Scrum team is in trouble of missing their commitments?

So why isn’t the team meeting its commitments? Usually, this phenomenon is caused by overcomitting at Sprint Planning or by surprises during the Sprint that cause stories to become much larger than their original estimations. However, a third cause that would not appear on the Sprint Burndown is related to untracked changes in team load or capacity during the Sprint. When a new story is added to the team’s load during the Sprint because “it just came up” or “it’s really important” or “it won’t take long,” the team’s ability to meet its original commitments is challenged. Likewise, when a team member is unexpectedly removed from the team (for many of the aforementioned reasons), the team will often not fulfill its Sprint Planning commitments. When either of these events occur without properly following the Scrum framework (that is to say, canceling the Sprint and reworking the team’s commitment), the tool can neither stop it nor properly report it. A software tool can’t force you to make good decisions or to track what you did.

I’ve also fielded many requests over the years for better time tracking in our software tools. These come in a variety of flavors: How many actual hours were spent on a task?; What’s the difference between actual and estimated hours?; Who on the team has assigned themselves to too many tasks? Or too few? These questions always set off an alarm for me when I hear them because, almost every time, they signal a possible misunderstanding of Scrum that could be VERY detrimental to the team. Each of these is a potential poison. Accounting for these poisons in our software tools can’t provide a cure for their effects – we have to look closer to the source for the proper cures.

Interestingly enough, in a marketing strategy to beat all strategies, the unicorn horns sold by Scandinavians through Viking and Arab middlemen ended up being nothing more than an incredibly well kept, centuries-long hoax. While the Scandinavians made millions, what they were selling to European royalty and the church were nothing more than the abnormally long teeth of the arctic Narwhal (http://en.wikipedia.org/wiki/Narwhal).

There was no magic cure then and there’s no magic cure today.

In truth, we create the poisons that pollute our projects. We call them emergencies, business priorities, contractural requirements, customer satisfaction issues, must haves…you name it. Whatever we call them, we cannot rely on software tools to protect us from ourselves. We must rely on ourselves. The cure for what ails our projects is, quite simply, discipline. We must discipline ourselves to abide by the few guidelines that Scrum and Agile development put forth in order to be effective. Not that this is shocking news for software developers. After all, how often does the development process actually have a fairy tale ending?

The comments are time tracking makes sense. But not sure what is the potential poison. I think the tool should support getting this data so that the team can use this data to self organize or for a team of junior engineers, Scrum Master can help organize or distribute the tasks.
Actual hours spent vs estimated hours – The tool should support it, but its usage left to the team. A team member may use it to get better and also might be plan and organize better.
Also please explain why this is deterimental.

By the way, I would question the title of “ScrumMaster” for anyone who is distributing tasks, committing to work on behalf of his team, etc. The ScrumMaster is a coach serving his team, creating conditions for self organization. Not a taskmaster.

It’s hard to add to what Michael has already said – when task estimates become measurable (that is, they are compared against actuals), unwanted behaviors will occur that will cause team members to misrepresent tasks status or complexity or even to decline to take on certain tasks without extensive upfront analysis to ensure that their estimates are much closer to the actuals when finished.

But let’s take this whole matter even a little further. I posted a new blog entry here to write out my thoughts on task estimates. Please take a look and come back here to let me know your thoughts.

Regarding sprint lengths I agree with you, but I’ve also seen and experienced situations where having one sprint shorter/longer than usual makes sense. Specifically with teams working with legacy code that needs a stabilizing sprint at the end where the normal sprint length is say three weeks and they need a two week sprint for stabilization. Some might not call this a sprint at all and don’t use any tool to monitor there progress and just start finding/fixing bugs.

Regarding a tool like ScrumWorks supporting varying sprint lengths I think that could be ok, though bearing in mind that the user might misuse the tool as you mentioned in your post. But is it the vendors job to put a safety harness around the tool so that the users should not misuse it? Should the tool warn you if you create a sprint with different length than before, and argue why this is bad?

Your point about time tracking I fully support. I also get a bad feeling when this comes up and I can’t really clearly explain why. In general I usually state that keeping track of time spent and keeping track of progress are two different things, and only one of them fits my view of Scrum. I therefore also recommend using two different tools, one for time tracking and one for “Scrum”.

As for Sprint lengths, I agree. There are times, like near the end of a project, that a shorter length can be beneficial. However, modifying more than is absolutely necessary is simply not advisable.

As for the tool protecting itself from unexpected use — I feel very strongly here that a tool could never and should almost never act as a guardian against what it’s users want to do. Why? Because a tool can never be certain that it’s aware of all of the realistic effective alternatives. Should it warn against potentially ill-advised uses? Sure, but only if the user can turn those warnings off. Although, even there you should pick what you need to warn about. Apple has had a field day laughing about Vista’s warning. Obviously, there’s a limit. In my experience, it’s usually not the tool that causes the problems, but the lack of procedural discipline that is a root cause.

As for that “bad feeling” you get when people want to track actuals, I used to get those too. I still do, in fact, but now I know why. It comes down to this, if we had machines performing Sprint Backlog tasks, we could eliminate almost all of the circumstantial causes that effect machine performance. In other words, other than temperature, humidity, parts maintenance, and the quality of the inputs, machines will perform the same and similar tasks within a very slim variance in elapsed time. When you replace the machine with the human factor, you introduce uncounted variables that affect the completion of the task. Skill level, task focus, how much sleep the developer got the night before, etc.

All of these variables affect the performance of the developer and not necessarily within a very slim variance. In my personal experience, there are times when I can knock out complex code or detailed documentation in my first attempt and there are times when my first attempt makes me look like I’ve never seen a computer before.

Therefore, comparing one task to another similar task might seem simple on the surface, but once you throw in the entirety of the human element, it’s a whole new ball game.

I much prefer using Sprint Retrospectives to find out what is working and not working for the team. It doesn’t seem scientific, but it is effective and routine retrospectives (once after every Sprint) helps to “tune” the environment, recognizing that what works one month may not work the next because of the humans on the team.