How to nail Scrum ceremonies and stay on top of the dev process — Product owner guide part III.

Welcome to the third and last part of our free guide for product owners. We have already described how to quickly kick-off new products and how to write crystal clear User Stories.

This time, we explain how to set up the team and processes for development. So prepare to learn more about step-by-step development planning and tips about a new dev team onboarding. We’ll dive into ceremonies and the way they should be held and also cover the process of QA. Enjoy!

Preparation for development

1. Present Epics, Vision, and Roadmap to the team to set expectations. Repeat this step whenever a new topic or more significant changes in the product’s strategy are introduced.
2. Present Priorities for each release based on the high-level user stories -> Release (1,2,3..). Validate priorities with the team. This step is completed during Refinement with the team.
3. Present user stories. Let the team give feedback, add details and ask questions. This step is completed during Refinement with the team.
4. Create estimations (story points). This step is completed during Refinement with the team.
5. Validate estimated backlog with stakeholders and analysts.
6. Make Sprint planning.
7. Continually validate backlog — check dependencies, priorities, etc.
8. Get feedback from stakeholders after Demo.
9. Make Retrospective.

Points 2–9 repeat based on iterations and needs.

Scrum Ceremonies
Although the scrum is in no way rigid, it is good to follow patterns that keep the effectiveness high and smoothen the development process.

Backlog Refinement (Responsible person: Product Owner)
1. The Refinement can be executed anytime during the sprint.
▹ Best time: Middle of the sprint.
▹ Alternative time: The beginning or end of the sprint (When done at the end of the sprint, there’s a risk that User Stories won’t be ready for the sprint planning).

2. Have a draft of User Stories prepared 1 month or 1 release before the Refinement in which you want to discuss them so that the team doesn’t have to rush to finalize specifications just before the sprint planning. Why is it only a draft? Because there is no reason to spend a lot of time preparing detailed stories and then throwing them away. It is only an overview of where we want to go in 1 month and a good resource for designs, architecture, etc. We also follow two simple rules:
▹ Have user stories finalized 2 weeks before the planning.
▹ Have a backlog prepared ideally for 2 sprints in advance.

Steps of the Refinement:
1. Break a big User Story into the smallest possible details that a PO can distinguish.

2. Send the prepared US to the team for Q&A. This step requires a process, and it must be clear what is expected from the team. Many developers don’t know what they should focus on. The typical answer is: “I’ll know when I start working on it.” No! It’s too late. This is not how the scrum works.
Things that the team should check:
▹ User experience -> check the target functionality.
▹ User flow + design.
▹ Discuss a relation between BE+FE.
▹ Is the tech solution covered in the documentation, or hasn’t it been implemented somehow?
▹ Non-functional requirements.
▹ Acceptance criteria (if relevant).
▹ Testing — How a user story will be tested?
▹ Think of corner cases and out-of-scope things.
▹ Think of possible solutions.

3. PO will add or edit information based on the questions.

4. Refinement meeting (as needed but max. 2 hours)
▹ PO describes Epic + US.
▹ PO presents a draft of split user stories.
▹ Discussion with the team.
▹ Result -> Prepared User Stories for the estimation. Doing estimates during the refinement is beneficial for several reasons: you already understand the complexity of the sprint, have statistics for velocity, and can synchronise views on an estimation.
▹ If the US is not ready yet, then return it into the feedback loop.

Sprint Planning (Scrum master)
The purpose is to include the calculated User Stories into the sprint based on the velocity. The team must decide what is achievable in the sprint. PO is in charge of priorities. User Stories should be planned for the whole team and not assigned to individuals.
1. The meeting can be held right after the Sprint review with fresh insights. It doesn’t have to be on a fixed date and time.
2. Focus on velocity.
3. Check the capacities of team members.
4. Choose a different day for this meeting than for the retrospective, so there is time for the team to think about possible improvements before the new sprint.
5. Have 30 % of the sprint reserved for the operations and technical part (this time is used by the team for improvements and bug fixing).
▹ This time can also be reserved for technical tasks from the architects’ board or from the team’s backlog. If the estimated solution time for the Technical task exceeds 2 MDs, it should be evaluated by a Story Point and compared to the official goal of the sprint.

Results:

1. Defined priorities.
2. Sprint goal.

One of the most important rules is that the team doesn’t move forward until one functionality or a User Story is finished. By following these habits, you always get a testable product. Go feature by feature. The team’s output should be based on delivery, results, and value, not the spent time.

Sprint review (Scrum Master)
The sprint review meeting should always focus on the product. Discuss the pros and cons of the product development. Apart from the team, even stakeholders are welcomed at this meeting. It’s an excellent opportunity to sync everyone and discuss changes in the backlog, market, or business with stakeholders.
The sprint review is also great to get multiple teams that participate in the project on the same page.

Points for discussion:

1. What was planned?
2. What has been done vs. what was planned?
3. What needs to be moved into the next sprint? And why?
4. Are there any changes in the backlog, market, or business that impact the backlog?

Sprint Retrospective (Scrum master)
The retrospective concentrates on the team and methods to constantly improve the efficiency and satisfaction of team members.

1. Check the progress and tasks for improvement from the last retrospective.
2. What works well and what does not?
3. How to keep good things going and reduce the bad ones?

To keep the retrospective efficient and get the best results, try these tips:

1. Prepare specific questions for each retrospective to set the direction of the meeting. During one retrospective, you can focus more on the communication in the team, and during the other, you can dive into development processes.
2. Each member should have 5–8 minutes to write down all points, and then they’ll be presented and discussed in the team.
3. Use tools to collect feedback from the team and don’t forget to share it so that it’s available for everyone
4. Ask “why” a lot to understand motivations and reasons.
5. The team should always identify downsides and room for improvements. If that doesn’t happen, an external person should be invited (designer, tester, stakeholder).
6. Try to create a self-reflection of each member for self-improvement.

Result:
▹ Have identified issues and weak spots of the team and calculate with them when planning a sprint.

Useful tools for Retrospective:
https://easyretro.io
http://www.polljunkie.com/poll

Daily Status (Scrum master)
The daily status allows team members to get support right when they need it. There is often an issue that developers don’t want to attend the status.

Here are some tips to motivate developers:
➡ They need to realize it’s not a status but a short daily planning meeting for developers.
➡ The questions of the meeting should be: “How do we make progress to achieve the goals of the sprint?.”
➡ This meeting is made by developers for developers — there is no reason to gather updates for PO or SM.
➡ Keep it short — 15 minutes slot should do.
➡ Try different formats. There are other approaches than just asking 3 routine questions. Find a different way for your team, which will be valuable for everyone.Testing & Bugs
The ideal process of solving bugs is to include the QA into the development process and continually test the User Stories as they are finished. After the sprint, when all ACs are approved by the product owner, the QA should test the User Stories with the broader picture of the whole product in mind.

When the QA identifies a bug:

1. Analyze and prioritize the bug.
2. The output of the analysis can be a technical User Story.

If the priority is high, the bug can be fixed directly in the sprint because 30 % of the capacity is dedicated to operations that include bug fixing.

I hope you enjoyed all three parts of our guide for product owners, and you’ll find our tips valuable for improving your workflow. We would love to hear your feedback, so feel free to reach out if there is anything you have to say.

Reach out to get more information.
Martin, co-founder & Pavel, Product Owner