0

I have bought Jira for my hobby project and I am currently creating epics, user stories and tasks. I have a question regarding organization and registration of tasks.

1)

I have a user story that is: "As a candidate I want to see which services I have access to". Tasks belonging to this user story is:

  • Create service for listing all services that a candidate have access to
  • Create SQL-script
  • Create models for database tables
  • Create a service for returning detailed information about a service

2)

I have another user story that is: "As a buyer I want to see which services that I can buy". And the tasks are:

  • Create service for listing all services that is available
  • Create a service for returning detailed information about a service
  • ...

The thing that doesn't feel right is the task: "Create a service for returning detailed information about a service". It is duplicated because I don't know how to handle/what to do when a task applies to multiple user stories? Is it normal to only have that task in the first user story that will be done first? It is a requirement for both user stories, but I can use the same service for both if you understand what I mean?

|improve this question
1

Yes it's normal, because you've already finished the task. You estimated some time for that task and you worked on that task. So that makes it perfectly normal to skip that task for other stories that have the same task.

If you want (for history purpose) you could write that task again for the other story and put 0 in estimated time, just so you know you've finished it. Then you can keep track of what you had to do to finish that story.

|improve this answer
  • I would strongly recommend to put the 'duplicate' task in initially. That way you have a task to fall back to if it turns out the services aren't identical after all. But that can only be assessed when you look in detail at both tasks or a task and what you already have. – Bart van Ingen Schenau Sep 21 '14 at 12:25
  • @BartvanIngenSchenau Yeah, this may be a simple scenario where I only have two user stories but when I get 100 for instance then it would be harder to remember what you have and what not (even though I probably will since I am the only developer). Do you estimate the duplicated task as normal? – Andy Sep 21 '14 at 12:29
  • @Andy: I estimate the task as normal (at the planning session of a sprint, based on what I remember as having been implemented so far). If I mis-remember, then the task estimation will obviously be way off, but that hasn't been my experience so far. – Bart van Ingen Schenau Sep 21 '14 at 15:59
0

I've always considered user stories as documented requirements and tasks as implementation plans or hints.

It is very likely that two or more requirements will end up reusing the same code or infrastructure. This is why it's possible for two user stories to require the same tasks.

In order to get around this, I typically won't specify my tasks until right before my sprint begins. This means I'm specifying an implementation plan according to the current state of the project. If my story depends on a Service X that isn't yet implemented, then I'll add a task for that. If, however, I managed to squeeze in Service X in my last sprint, then there's no need to write a duplicate task for it.

If, on the other hand, you specify your story tasks far in advance, then it's hard to tell what will already be implemented by the time you pick up a story. And that makes it hard to determine which tasks specify.

|improve this answer
  • And what if Service X doesn't exist yet, but two stories need it in the upcoming sprint? – Bart van Ingen Schenau Sep 21 '14 at 16:02
  • A very realistic scenario that I have no clean process for. In my previous team we called these situations "dependant stories" and we organized our sprint backlog in such a way to avoid blocking due to unresolved dependency. This usually involved putting one of the stories at the top of the backlog and the other closer to the bottom. It wasn't perfect, but it worked most of the time. – MetaFight Sep 21 '14 at 16:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.