Breaking Down and Refining User Stories
Another way to look at tasks and user stories is to determine how many people will be working on them. User stories may involve several people and roles to complete. Analysts look at the technical requirements, while developers write the code, and QA technicians make sure the feature works as designed. Tasks are the responsibility of a single person or role. Each part of the user story can be broken down into a distinct task.
Developer Role in Creating Tasks
With developers handling only tasks for writing and maintaining code, it may seem like they have no part in creating the tasks. However, the developer role has expertise that no other role on a Scrum team has. They can be valuable in making sure tasks are created properly, with logical divisions. The entire process of creating tasks benefits from the input of developers and other roles of the Scrum team.
Committing User Stories
The first step in the creation of tasks is committing user stories. As the product owner researches what stakeholders want, they add user stories to the product backlog. Once the product backlog has all the user stories that the stakeholders want, they must be prioritized. Before the sprint begins, user stories are committed to a sprint. This locks down an estimate for which user stories the Scrum team believes they can finish before the sprint ends.
What does the developer role get from the committing stage? Being present in meetings about committing user stories gives developers a heads up about what they will be working on. This gives them the opportunity to research the features, and analyze what needs to be done. When tasks are broken out and estimated, developers will need to know details. Getting an advance notice from the committing process allows developers to anticipate the next steps.
Recommended Further Reading
The following materials may assist you in order to get the most out of this course: