Simple method for handling tough task breakout sessions

Sometimes you may find that developers have a really great understanding of the business value of a story and understand what needs to be built but then the nasty implementation discussion begins and the team has a hard time figuring out how to do their task breakout.  “How do we know the tasks when we don’t know how it will be built?”

Stories need to be dissected right about the time the sprint is supposed to start so the story is small, testable and can fit into the sprint.  That’s the easy part, in theory.  What about when a user story has clear business value, everybody gets it, the story is BIG (in terms of points) and nobody can figure out how to break it down?

Here’s  a technique we tried today and it seems to have been successful based on the output.  We set a timeboxed discussion to 15 minutes and the architect of the group took the lead and wrote what the main criteria of the solution was.  In this case it was building a new component that would interface with our product so technically it was a ‘build from the ground up’ type of thing requiring some architectural discussion.

The component needed to be:

  • scalable so it would work in our environment (load balanced, redundant etc)
  • restartable without manual intervention (watchdog approach)
  • secure
  • testable

There were a few other buckets, but that’s not so much important right now.  The architect drew 3 feasible technical solutions on the whiteboard pretty quickly and everybody got the gist of it.  Since we had 3 solutions, each criteria specified was ranked by each team member with a 1, 2 or 3 with a 3 representing that a certain solution was the best for each particular category.  Here’s a rough idea how the scores came out.


What was interesting is that some team members ranked certain solutions as a zero in a particular category.   This chart tells us that solution 3 is probably not an option.  Although we didn’t do this due to a time crunch, you could get creative and apply a weighting to the categories.


Solution 1 is still on top, however if the weighting for Category 1 and Category 2 are switched, the numbers are much closer for Solution 1 and Solution 2.


While not completely fool proof, this simple ‘Kano’ type of analysis (sans the questions) typically used for product development can come in handy in a pinch to quickly get to an answer without long and drawn out (read: exhausting and frustrating) conversations.