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?
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.
3
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.
2