We are using JIRA to manage the scrum process. What I'm curious about is whether the User Story issue type should be assigned to a team member, the PO, or remain unassigned. My gut tells me it should remain unassigned to be assigned to the PO since the team should only be working on Task issues, but I wanted to see if I'm missing anything.
Add a comment
|
4 Answers
There is no hard and fast rule about assigning User Stories within the tool of your choice (some tools may not even support it). It all comes down to how you are using your tool.
If you are using the User Story items merely as a container for Task items, without any defined states or transitions, then it is most logical to leave the User Stories unassigned.
It you transition the User Story items from Open to In Progress to Done along with the Tasks they contain, then you might assign the User Story to the person responsible for keeping the User Story state consistent with the states of the underlying Tasks (which can even be the scrum master), or you can leave it unassigned if that is a team responsibility.
answered Aug 31, 2013 at 7:34
It really does not matter unless
- you have given a certain meaning to the assignee field (within the Scrum team's workflow) - e.g. assignees check definition of done before passing story to PO
- you are passing along the issue through certain stages (as part of a bigger workflow, e.g. from team to team with one respective team lead as the assignee)
Remember that in addition to the assignee field you also have certain statuses. Typically, I would say that the status is enough and that an assignee is not necessary, but you might feel that this is better suited to your needs. Both can achieve the same thing.
I think it all depends on your team and the problems your team is trying to overcome.
If your team is having trouble completing user stories, or if you find the user story's tasks drift away from the text, then yes have a story assigned to someone. It will be the story owner's responsibility to ensure tasks meet the goal of the story, all tasks are done-done, and the sum of all tasks completes the story.
If your team doesn't have a problem completing user stories, then why bother? Don't use process as a straitjacket; use process as a tool to solve problems.
answered Aug 31, 2013 at 17:42
for example I (Scrum Master) use the assign area to assign developers to prepare the refinement for this story. The PO will do a check validation if the team can spend time on this story and assigns a developer to the story (and will have the first contact with the stakeholders if this person was not yet known to the team). The developer could have contact with the stakeholder to ask for more details on the 'what' (wished functionality) and 'why' (value) and already fill in the describtion area. And later on introduceses the story in the Refinement event. Where than the whole team can talk about the 'how' (solution) and adds the answers and info in the story. Later on in the Sprint Planning this person can still be the assignee or it will change. In the Sprint you than have somebody who can coordinated the tasks, when there are more developers on the tasks assigned.
