This article looks to discuss ‘Creating User Story Tasks in Agile Projects’. It provides an introduction to creating Tasks, along with the Agile Product Backlog.
Agile User Stories and Tasks
A 59 Seconds Agile Training Video
Creating User Story Tasks for Scrum Masters
A 59 Seconds Agile Article
According to The Agile Manifesto: “The best architectures, requirements, and designs emerge from self-organizing teams.”
As a Scrum Master, your job is to help your team become self-organizing. Thanks to the Scrum framework, you have what you need to help the team own their tasks in the project.
Creating User Story Tasks and The Product Backlog
Everything a Scrum Team needs to work on is in the Product Backlog. The Product backlog is simply a list of the things users and customers want from the product, grouped by epics, features and user stories. A popular format of recording a product backlog item (PBI) is writing down user stories. “As a (user role), I want to (describe action here) in order to (describe value or desired output here).”
A good PBI is understood by everyone. They know what its objective is, what the desired outcome is>. They know what level of complexity and feasibility it has. The team can opt to use an online tool to manage PBIs or a physical board with swim-lanes – whichever is more manageable. Ensuring that these characteristics are followed will help the development team have a better picture of what they need to do.
Creating User Story Tasks and the Sprint Ceremonies
While the Scrum Master can coach the team at any point during the project, the Sprint Ceremonies are the most important activities in the timeline and also the best venue for managing the work to be done. This is where the team inspects the work done and adapts to changes for upcoming work. While each ceremony has different purposes, they all have an impact on what tasks the team will accomplish.
The first part of Sprint Planning is used to identify what to put into the Sprint Backlog. This is where the Product Owner identifies the Sprint goal, scopes what backlog items to include, and prioritizes the Sprint backlog from the most important to the least important. The Product Owner must be able to clarify what the functionality is and why they’re valuable. Acceptance criteria should also be discussed so that the team will know what to meet in finishing PBIs.
Our Favourite Agile Books
We found these books great for finding out more information on Agile Scrum:
The second half of Sprint Planning is where the team discusses how to finish the Sprint’s product increment. Tasks for each PBI are identified, and because tasks are never assigned to a Scrum project, each team member picks tasks for themselves. More experienced team members can take the technically challenging tasks, while less experienced ones can choose simpler tasks or be mentored for the more difficult ones.
If not yet done during Product Backlog prioritization, the team also estimates the complexity or amount of time needed for each PBI. One way to estimate PBIs would be to use Poker Planning, where everyone votes for the agreed Story Point, a number relative to the complexity of the PBI at hand. The total Story Points in a Sprint indicates the total effort needed to be given. While the Product Owner may choose not to take part in this session, it’s beneficial to have him around in case the team needs to clarify or renegotiate the scope.
The Sprint Review is the ceremony primarily used for inspecting the product increment of a Sprint. Each PBI is demonstrated to the Product Owner (along with other customers, if available) and feedback is taken for each PBI. If not done during the Sprint, PBIs are assessed if they meet the Definition of Done or if they still need to be worked on. The feedback gathered can also be used to come up with future PBIs, which, in turn, will create more tasks for the team.
The Agile User Stories and Tasks
A 59 Seconds Agile Video Animation
User Stories Applied
A 59 Seconds Agile Book Review
User Stories Applied by Mike Cohn is one of our favourite books on Agile User Stories. The book starts with an overview into user stories, and details what a user story is and the different aspects of them. He then discusses how to go about writing a user story, and provides details of the INVEST criteria that can be used to determine if the story is meeting all of its objectives. Next Mike gives an in depth discussion of who user stories are written for and where to begin when gathering the details for them. The book then discusses acceptance testing user stories, including how to go about specifying these criteria and the responsibilities of the development team and customers during this process.