As is defined by Mike Cohn Scrum encourages teams to breakdown stories in the Product Backlog into tasks which are 8-16 hours worth of effort and which become a part of the Sprint Backlog. These are the tasks which the team commits to completing at the end of a Sprint (which can be 2-4 weeks).
The problem with breaking a good user story into tasks like "Create the UI", "Develop the Service", "Test the Service" etc... and maintaining them separately in a backlog , is that it encourages Scrum Masters to allow different people in the team to pick these bits of tasks of a big user story. So a scenario where Bob (and his pair ?) works on the "Create the UI" task and Ron (and his pair? works on "Develop the Service" in parallel, in order to finish work fast is encouraged in the team.
Scrum templates like those proposed by Ken Schwaber, take it even further by asking people to track hours logged on these tasks. Not only is tracking tasks like these unnecessary, but if a developer does not develop a story end to end, he completely misses out the bigger picture of the architecture. This is where a team ends up with UI experts who know only JavaScript/HTML with no clue of the services layer and Services experts who just develop services without knowing their consumers.
The problem with breaking a good user story into tasks like "Create the UI", "Develop the Service", "Test the Service" etc... and maintaining them separately in a backlog , is that it encourages Scrum Masters to allow different people in the team to pick these bits of tasks of a big user story. So a scenario where Bob (and his pair ?) works on the "Create the UI" task and Ron (and his pair? works on "Develop the Service" in parallel, in order to finish work fast is encouraged in the team.
Scrum templates like those proposed by Ken Schwaber, take it even further by asking people to track hours logged on these tasks. Not only is tracking tasks like these unnecessary, but if a developer does not develop a story end to end, he completely misses out the bigger picture of the architecture. This is where a team ends up with UI experts who know only JavaScript/HTML with no clue of the services layer and Services experts who just develop services without knowing their consumers.
To me, a good user story which has business value, is the only unit of work I would like to track. Developer pairs in a team should be encouraged to work on complete user stories so that they understand the architecture end to end , and have the satisfaction of adding business value to the product they are working on. This is extremely important but unfortunately I have seen many adopters of Scrum mislead by popular Scrum literature available.
Great post Anand. Interesting opinion, and one I agree with. Some of the teams I've worked with break stories into tasks and some don't. Having said that, no team I've worked with had a single task that would take between 8 and 16 hours to complete. Usually it was much less, so the time it would take to break stories into tasks wasn't worth the effort. Regardless, if a UI person and a dev need to work together to complete a story, they can do so whether you have tasks or not.
ReplyDeleteI completely dissagree. There's great value in not only designing the software, but also in designing the work (http://is.gd/51rUH).
ReplyDeleteOne of the bigger mistakes we tend to make with Scrum is to apply it to managing work. Scrum is better than a kick in the head, but there's more to achieving desired outcomes and improving upon them than what is offered by colloquail Scrum.
There's nothing in a work breakdown for a feature that suggests that a team can choose willy-nilly from outstanding work items without giving thought and consideration to whether their choices are right, good, and productive. If a team is making the wrong choices in the way that it is sequencing work, including choices on who's doing what, then this issue should be addressed and countermeasures pursued.
Over the years my attitudes to tasks have changed dramatically. After over 10,000 hours of coaching scrum teams, my current feeling is to use tasks when they are helpful in defining the work involved in implementing the story, and accept that parts of a story or task might be implemented by different people, but I leave the division of labor to the team and I don't track task completion. The guy who pulled the story remains responsible for delivering it and I don't track it until the team agrees that it's been hallway tested, QA tested, code reviewed, and accepted by the product owner.
ReplyDeleteI think it's a natural process to break down work. I also think it's helpful when working in a multi-disciplinary organization to have some people focus on defining the scope of what needs to be done and others focus more on how to do it, and what needs to be done, specifically, at the micro level.
ReplyDeleteFor instance, if you're writing accounting software, the accountants should be the people defining the stories, determining requirements etc. and the developers should be the ones figuring out how to implement, etc.
To me, stories are more for the functional, subject-matter expert side of the house while tasks are more for the 'make it happen', or 'just get it done' side of the house. The real challenge is finding a way to get the two sides to meet in the middle. And I think that phrasing requirements as stories is actually an excellent way to do that. It makes for a nice collaboration.
@Laran Developers should as much as possible develop business units of work, which is to the very minimal, a user story.
ReplyDeleteAnd as you mention, the challenge in making developers and business come on the same page is through a good User Story