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?
Agile Forest 
Hi Renee, I hope you’re on the mend and feeling better. I have just been on a Certified Scrum Master course, and struggled to understand the benefit of breaking story cards into tasks. I have had experiences where I felt micromanaged at a story card level, so can’t imagine detailing what I’m doing on an hourly basis would be any better.
Thanks Ryan for popping in. I see you are at a new environment. I hope you enjoy the change!
Hi, Renee, happy valentine!
I have similar experience. We broke down user stories into tasks in our first agile project but in the second project, team members decided that they were spending too much time updating these tasks. Eventually, we monitored in user story level but need to keep user stories small.
I believe doing a user story is like painting a picture which works well with tacit knowledge. We will do a bit of this and do a bit of that without following a definite plan. Breaking down a user story into tasks is effectively forcing people to produce explicit knowledge out of tacit knowledge. This will result in inefficiency and inaccuracy.
I believe managing in user stories level is fine provided that user stories are small enough (small WIP).
Michael Leung
Thanks Michael – that is a great way to put it.
I like that analogy to explicit and implicit knowledge. In my experience, when a manager doesn’t have trust in their team, or the team doesn’t have trust in each other, they tend to add tasks, and the more explicit the tasks the better.
Its seems to be about trying to make sure that nothing gets missed, or trying to determine how a feature will be implemented during the breakdown session: essentially it becomes a little design meeting, with everybody contributing.
My current team has always done breakdowns of backlog items in tasks for each item selected into the sprint (but not before). Sometimes they would be fairly standard: db change, service change, ui change, maybe something extra to fill it out.
We’re starting to make the backlog items smaller, and to leave the tasks to the individuals doing item. I believe because there is now more implicit knowledge spread among the team, so it doesn’t need to made explicit.
I’m not sure whether having tasks is micro-managing. It may be just a way of transferring that knowledge, or maybe (pessimistically) for more strongly opinionated team members to impose their views on others. Either way, removing tasks goes back to trusting the team to do the best job they can, both for the manager, and between team members themselves. And if the work is not up to scratch, then providing education along the way.
On more explicit micro-management, we still in the phase that backlog items are “owned’ by an individual, rather than the team. That team member is expected to do at least the bulk of the work. Backlog items are often assigned to team members by the development manager, based on their experience in that area of the code. I believe that this, again, is truly a trust issue, and in the end only degrades the quality of the code base.
Hi Renee – hope you’re feeling better and good to have you back 🙂
Any management of the actual work (tasks) by the Scrum Master, other than at the requirements level when helping the product owner, I would deem inappropriate and contrary to self-organisation.
The SM ought to be helping the team stick to their own agreed processes, so if the team agrees to do task breakdowns and then don’t it’s something to be pointed out (in retro, perhaps). But I don’t think the SM should be involving themselves with the tasks themselves.
It’s very easy to slip into micro-manager mode when teams work at the task level. I’ve been guilty of that myself many times. My preference is for the SM to put an emphasis on coaching better practices (i.e. small stories, swarming, getting things “done”, etc.) rather than enforcing Scrum, per se.
Hi Renee, some intersting observations and in particular I like Phil’s take on explicit andf implicit knowledge. What I would add is to consider the context of the team and where they might be comng from.
If the team you are working with come from a low trust environment, where the business has been very task oriented with them and a variety of capabilities and experience exists, then may be what we would consider micro management doesn’t feel the same to them. Given a different environmental context, then no doubt a different conlusion could be drawn.
Trust, capability and maturity are all important relationship factors that impact upon the approach best suited to any team. That’s where the Scrum Master is invaluable.