Excel as a Test Management Tool

Because you're going to use it anyway...

Ruby-Selenium Webdriver

In under 10 Minutes

%w or %W? Secrets revealed!

Delimited Input discussed in depth.

Managing Knowledge Transfer Sessions

Read the article, grab the templates

Ask questions

If you don't ask, you won't learn. You won't teach either.

Friday, 19 November 2010

Burndown - are we tracking the right things?

I saw a tweet this morning by Mohinder (@mpkhosla) that pointed to an article that made my blood boil.



http://www.infoq.com/news/2010/09/Sprint_Burndown

I must have missed the tweet, blog post or some other place where I was to learn that tracking Burndown should be done in hours. Why do I think that is influenced by traditional project management? I’ve always tracked Burndown by tasks. Tracking Burndown by hours is pointless, it tells us nothing about the actual delivery of usable functionality within a given sprint. How do we deliver usable functionality? One bit at a time, so we care about the delivered bits, those bits being delivered by completing tasks, not by working a number of hours.

Hours are just a sizing tool to see how many bits can be done in a given sprint of a certain length, say 2 weeks. That would give us roughly 80 hours per person, 64hrs if you want to plan at 80% efficiency, work it as you will. But if I log 80 or 64 hours how much work have I delivered? If you ask me in these terms you’ll want to know other details such as how many test cases I managed to prepare, automate or execute. As that’s what we really care about let’s track that. You know I’ll be here this week, ill or on holiday and tracking that is a project management type activity, an admin task, that is done away from the Burndown so don’t even think about this aspect in relation to your Burndown.

When planning testing tasks I have the team estimate the testing effort required to test a given item. We estimate in hours. When possible (when the Client ‘gets’ it) I add our test estimation to the task card next to everyone else in the development team*.

On the Burndown horizontal axis we can plot the number of days in the Sprint, in the vertical (y) axis we can plot the number of tasks we’re looking to complete on a given day. We know how many we can fit in the given Sprint days because we can divide the total hours in the Sprint by the hours we’ve estimated for the task. Math is great.

Now each day we can agree what tasks to work on and deliver them...or not. We track tasks complete/items delivered, not “I came into the office and did some work therefore that should automagically represent progress”
nonsense.

I'm sure you've seen a Burndown but just for context I'm meaning this one that I create in Excel, if I'm needed to create one that is.



* The Development Team is not just Developers, it’s all the other teams such as; Client, Business Analysts, Technical Authors, Developers, Testers, Build, Operations, Support. All are involved in the development of
working software that solves and continues to solve Client (customer) business problems. Therefore they all have a say in how long their tasks take that when completed will get a bit of working functionality done-done(done{done}).