Agile Problems: Story Points and the Un-Sizeable Task


Agile planning relies on the concept of well-defined user stories, with a clear sizing in story points.  These story points are abstract representatives of how difficult a task will be for a team, and may vary by team.  For software development team A, a story point may be roughly two hours of work.  For development team B, a story point may be thought of as a day’s work.   The consistency of a story point matters only within an agile scrum team.   Sizing is relative and specific to a team.

Sometimes the real world does not mesh nicely into the ideal agile world.   Sometimes work involves technology investigation, researching a lengthy spec to see exactly what the story is in the first place, or simply involves a new area of work for the team.  How should these be handled in the concept of scrum?

This type of work can be handled in a variety of ways.  The way I’ve seen work best, is to create a research story.  The research story is time-boxed and scopes the investigation.  The team member that takes the research story then comes back to the team with a summary of work and better understanding of the task.   There are of course times when a team member overachieves, discovers that the work is easier than thought and completes the work within the time-box dedicated for research, but this is usually not considered a problem.  There are also cases where the x days devoted to research are just not enough and another research task must be added.

Have you used timeboxed research stories?  What other techniques do you find useful when tasks are difficult to size?

Comments are closed.