Scrum Task Creation in Agile Projects

This article looks to discuss ‘Scrum Task Creation in Agile Projects’. It provides an introduction to the Scrum Task Creation and discusses coming up with User Stories.

Scrum Task Creation in Agile Projects

A 59 Seconds Agile Training Video
Agile User Stories and Tasks

Scrum Task Creation For Product Owners

A 59 Seconds Agile Article

One of the challenges that Agile teams face is knowing how much work they can finish. They also need to know if they have the capacity to take on the work they want to do. Over time, they will mature and get better at committing, completing, and delivering the product increment. But this will take a lot of teamwork and collaboration. As the Product Owner, you should be able to help guide the team in effectively creating tasks. This enables them to deliver value.

Scrum Task Creation: Coming Up With User Stories

Part of being a Product Owner is getting in conversations with your customers and users about their needs and feedback. It is from these conversations that ideas and requirements come from, as well as the validation of ideas and solutions. When the product is already in development and the Sprint ceremonies are already being held, these conversations can also take place during the Sprint Review, where stakeholders give their feedback, which in turn can be turned to requirements, features, and user stories.

59 Seconds Agile - Scrum Task Creation
59 Seconds Agile – Scrum Task Creation

Sometimes, user stories can be enhancements to both the project’s product and processes. For example, if the team wants to configure their servers for continuous integration and deployment, that will take time but will be beneficial for the project as it will help save time and prevent errors. The Product Owner will want to make this task visible to stakeholders and show the ROI of process improvements.

Scrum Task Creation and the Product Owner

Part of being a Product Owner is also managing the Product Backlog by adding, updating, and removing Product Backlog items as necessary. These need to be collaborated on with the development team because their tasks will primarily depend on the user stories. While this can take place anytime they are able to, the best place to do so would be during Product Backlog Refinement. Discussion on the user stories can continue whenever possible until it’s time to commit them to the Sprint Backlog during Sprint Planning.

Our Favourite Agile Books

We found these books great for finding out more information on Agile Scrum:

Breaking Down and Refining User Stories

When user stories are just newly ideated and entered into the Product Backlog, they are still very high-level and sometimes vague. Since the Product Backlog is a living document, it is normal to revisit it and refine the user stories and tasks for future Sprints. The nuclearity of Product Backlog Items will vary from team to team. The Product Owner and the developers need to work with each other to decide on that, but there is a simple guide that can be used for this.

Scrum Task Creation and the Definition of Done

If the Definition of Done is a guide for teams to know when a user story is completed for closure, the Definition of Ready is a guide for teams to know when a user story is ready to be worked on. Before an Agile team could properly commit to finishing work, they should be able to understand first what it is they need to develop. One way to know if a user story is good is if it meets the INVEST criteria:

● “I” is for independent. The user story can stand on its own, without covering functions of a feature that should be in a different user story.
● “N” is for negotiable. The user story invites negotiations and conversations.
● “V” is for valuable. Completing this user story will bring discernible value to the customers.
● “E” is for estimable. The user story is clear enough to be sized and estimated.
● “S” is for small. The user story is small enough to be included in the Sprint.
● “T” is for testable. The user story is understandable enough to generate acceptance criteria.

If a user story fails to meet any of the INVEST criteria, the Product Owner and the team will need to collaborate on it and further refine, clarify, and negotiate on the requirement until it passes the criteria.

Prev <— Continue Reading —> Next

The Agile User Stories and Tasks

A 59 Seconds Agile Video Animation
Agile User stories and Tasks with 59 Seconds Agile

Prev <— Continue Reading —> Next

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.

Prev <— Continue Reading —> Next

The Agile Frameworks

A 59 Seconds Agile Infographic
59 Seconds Agile - Creating Tasks
59 Seconds Agile – Agile User Stories and Tasks

Prev <— Continue Reading —> Next