Firstly I do apologise for the long absence on the blogging scene. This was in part due to my shift from Brisbane to Sydney, lack of internet, lack of technology, but also due to illness. So for my first blog back for the year I would like to implore you – PLEASE if as an adult you haven’t had any form of immunisation then go see a doctor and get some shots!
I was under the mistaken belief that I was fully immunised and didn’t need anything further in my adulthood and have been surprised to find that I was not covered when I got hit with Whooping Cough. Having been out of the country when the big Australian hoopla happened about Whooping Cough I was terribly ignorant of it and didn’t realise just how bad a bacterial infection it was. I am now six weeks into a three month problem and every day is very hard.
Thankfully I didn’t share it with anyone (but sadly my kids did give it to me as carriers). Anyway, onto the blog at hand.
My preference over the years has always been to work with User Stories as my lowest level of work. I have never really felt like I needed to break stories further down into tasks in the manner in which Scrum does. The reason for this is fourfold:
- I like my stories to be no bigger than four days. Ideally they are around the 2-3 day mark to deliver end to end. If they are this small then individuals can still be held accountable for progress on the story.
- I have rarely seen teams care about how a Story is being delivered whilst it is in progress. The fact that a team member is working on the unit tests now and then will be going onto the database changes has little consequence to the functioning of the other team members. The ‘aha’ and roadblock moments I see coming out of the Daily Standups very rarely arise from technical implementation at a task layer.
- The time it takes to break the user story down could be considered waste. For me the value in estimation is not the number you get, but the conversation of assumptions, dependencies and constraints that you have on the way to get an estimate. You can still have these conversations when planning the iteration.
- The extra time that it takes to generate a Burn Down chart. I would rather have a look at the where the stories sit within the flow against the current day of the iteration and see if the team is behind/ahead from that. It isn’t a science like the Burn Down chart, but if you really think two to four hours is going to make a big difference you are probably looking at the wrong things. I find that teams that focus solely on hours being Burned Down only tend to have a lot of carry overs due to a lack of focus on getting the story wholly to done.
So recently I started working with a team that, when I joined them, were already using tasks and hours to track. I made a conscious decision to not change or influence their desire to use tasks and consequently through myself with gusto into ensuring that all stories within the current iteration were fully broken down into tasks, estimated and tracked via a Burn Up chart (at the time there was too much volatility in the iteration from a change perspective to use a Burn Down).
What I found didn’t really change my dislike for tasks or burning down hours in the iteration but it occurred to me that when I focussed on work at an hour by hour basis rather than a day by day basis that I was becoming a scrum micro-manager. I instantly cringed at the realisation and wondered how empowered or autonomous the team felt from when they were being tracked at this layer.
So I asked them whether they felt that being tracked at a task layer, hour by hour felt like they were being micro-managed – the results? 71% of the team felt that it wasn’t micro-management, leaving 29% to feel the opposite. It would be interesting to see how this co-relates to performance, but I don’t think I will go into that on a personal blog.
Two of the team members did say they didn’t feel it was micro-management but expressed concern at the sheer visual weight of the number of cards on the wall. To put this into context at the moment we are mid iteration and have fourteen stories (consequently rows) in scope and around one hundred task cards flooding through the wall. This is ignoring the cards that are being fleshed out an iteration in advance (let’s ignore this slight scrumfall-ish behaviour), the product owner decision cards and the eighty story cards in the event horizon backlog. I do try to clean up the done work every day so that it looks a little less scary visually but at the start of Iterations I can definitely see it being a concern.
So what do you think – is it micro-management to track to the hour using tasks in Scrum?