Tag Archives: task breakout

Tips for Tasking Stories during Iteration Planning

Coaching tips,

The best thing about working with such a large organization is the exposure to multiple teams with varying types of work.   Different teams have different challenges which definitely keeps me on my toes.  One of most difficult aspects teams face, from my experience, is breaking down their stories into development tasks so the team can shift their mindset from each developer working on 1 story to having multiple teams members work on the same story simultaneously.

Some of the challenges with tasking stories is developers that have worked in traditional environments are so used to taking a big chunk of work and plowing through it over a day or few days that they simply want to create 2 tasks:

  1. Front end work – 1 day
  2. Back end work – 1 day

The next challenge is they instinctively want to check out both tasks at the same time because, well, this is always the way it’s been done and this is what they are comfortable with.  In general tasks should be able to be completed within a half-day or a full day at the most.  The benefits are that you’ll see real progress on the burndown and you’ll get more value out of the standup.

I’m sure this isn’t new and I’m sure other folks can relate to this problem so here are a couple of techniques I’ve used to help teams break their dependencies and allow them to split tasks up easier.

Experiment: Have the team work on 1 story and 1 story only during the iteration. While I have been met with resistance every time I try this, it does help the light-bulb to come on.  First reactions range from “this is stupid” or “this is impossible, we can’t do it” but every team I’ve tried this with as met with success.  Sure there are some stories that are too small and really only have 1 or 2 tasks, but by and large a team will be able to break their dependencies.

I’ve seen teams grab a projector and hop into a boardroom and work on a story together as a group.  One such team did “quad programming” and each person on the team learned something new about the section of code they were working on.

Track as you build: Maybe this should be a sub-set of experiment, but instead of focusing on 1 story have the team members agree to jotting down what they did when working on  story.

Take this story for example:

  1. as a website visitor I can email this webpage to a friend so they can benefit from the content.
    1. verify the user enters a valid email address
    2. verify the sender and recipient information is stored in the reporting database
    3. verify that when a user enters invalid data they get a javascript error message

As it’s being worked on by 1 developer some of the notes that could be jotted down might be:

  1. first I created the webform
  2. then I created the javascript validation based on the fields created on the form
  3. then I wrote the script to parse the form and invoke our sendMail routine
  4. then I looked at the form on the dev site to make sure it works

These steps can become tasks for the story.  A developer may think that the work must be sequential because after all they can’t parse the form if they haven’t written it yet and don’t know what the field names are but the team will figure out a way to break those dependencies.    In the retrospective, take the compiled notes and have the team talk about them.  Could we each have taken 1 task?  How could we build the parsing code while the form was being built?  Could we build the JavaScript on it’s own at the same time?  If 3 people were working on each of those aforementioned tasks could they do it by collaborating?

I often find that new teams are simply not used to working this way so it’s uncomfortable the first few times but as long as they are motivated and willing to be uncomfortable they will always find a way to break perceived dependencies, it’s just a matter of giving them a nudge.

Simple method for handling tough task breakout sessions

tactics

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.

post1.jpg

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.

post21.jpg

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.

post3.jpg

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.