Dividing scrum user stories into dummy tasks is evil

One of the keypoints of the scrum sprint planning meeting is the division of the user stories into tasks

  • it leaves less questions unclear to anyone, by dividing you find out more about the task
  • it helps provide better estimations
  • it gives all the team the same understanding of the user story scope, affecting at the sprint scope
  • it allows a better parallel work to happen, particularly on highly vertically specialized teams
  • team does it, team adapts it to the way to work (TDD, design mockups…)
  • the stories come up with their own roadmap which also serves as feedback for the PO
  • … I could add more stuff here

At the same time sprint planning meetings are considered a nightmare by some teams (quite hard yep). Earlier than later someone comes up with some sort of copy & paste candidate of a generic list of tasks as a solution to make the meeting lighter, for example

  • Write test case
  • Create db table(s)
  • Create db operation(s)
  • Create mockup(s)
  • Create front-end hmtl(s)
  • Integrate
  • Test
  • Deploy

The idea that may sound attractive, is just to add these subtasks to any user story without mercy

This is a severe anti pattern on scrum (I would say that for other scenarios on other software engineering frameworks).

But where does it come from? In the old times people were forced to fill activity reports, oftenly without a purpose or real benefit, rather as some form of slavery/torture after the actual work was done. People got really upset, and at the end everyone was so bored that started making a dummy copy & paste removing all the semantic of any task saying. I would say that this is fighting a bureaucracy that helps none something I agree with (if it is useless and compulsory, the best thing is to pervert the system, very true, sorry managers)

However we intend to do something different here. We try to leave the team space to work undisturbed but letting us know the progress and what to expect (for preparing releases, for setting the global scope, and so on). It is actually the way to analyse and understand the scope (giving room for further in-depth incremental proposes on the same aspect). In fact, all this work is the price to be paid for being both agile and self-managed, did I say that already? Is is not useless to also remember, that scrum is not the solution to all the problems of humanity, but if your project/company matches, try to do it well

I know, I know, it is a hard life, and if you happen to be Scrum Manager try to ease this work as much as possible for the team members (by preparing the sprint planning meeting the best you can, and enforcing the product owner to do so). There are other measures I would recommend before this, such as removing the hour estimation and working analysing backwards

But please don’t use dummy tasks!!

Something to say? leave a comment and sorry for the captain obvious post

 

Bytefilia