Question

Our team is getting started with using user stories for gathering requirements. We are experiencing some confusion about how they should be mapped to tasks. It seems we have several user stories that describes different aspects of the same fundamental development task. For example...

User stories:

  • As an XYZ user, I want to enter targets into a form, so that I can track progress towards them
  • As an XYZ user, I want to only be able to enter positive integers for a target, so that I can't enter erroneous data
  • As an XYZ user, I want to filter on available targets, so that I can focus only on particular ones

Task:

  • Develop a form for entering targets with validation and filtering

The problem here is that we are using TFS which prevents a development task from having multiple parents. Presumably this is because we are getting this approach wrong somehow in the first place.

Can anyone please suggest how this should be done?

Was it helpful?

Solution

We have exactly the same challenge in our projects. And it OK to have a task that provides (part of) the required functionality embedded in the user stories.

How we handle this:

  • Relate the task as a CHILD to the user story with the highest priority after release/sprint planning is done.
  • Relate the same task as RELATES TO to the other user stories.

In practice, the task hours are rolled-up into the first user story being processed. The task is then already done when the following user stories are put into sprints.

Would that work for you?

OTHER TIPS

Firstly in the example above the task has three components at least

form validation filtering

it looks like three tasks three stories

solved?

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top