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:
- Front end work – 1 day
- 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:
- as a website visitor I can email this webpage to a friend so they can benefit from the content.
- verify the user enters a valid email address
- verify the sender and recipient information is stored in the reporting database
- 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:
- first I created the webform
- then I created the javascript validation based on the fields created on the form
- then I wrote the script to parse the form and invoke our sendMail routine
- 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.