Creating Tasks For Product Owners

One of the challenges that Agile teams face is knowing how much work they can finish, and 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 so that they can deliver value.

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.

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.

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.

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.

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.

<– Continue Reading –>

Our Book Recommendations

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