In this post, I wanted to review a few tips for promoting a culture of sustainable value creation and sustainable pace with your agile teams. For teams that execute Scrum, the Scrum Guide provides a summary of expectations. After practicing Scrum for years, I still feel our teams continue to learn new tricks to foster value creation and promote work-life balance. We feel there’s a lot of art to it.
To keep this post actionable, I will organize the information as a checklist. If you want to dig deeper, feel free to check out the related links.
Product owner checklist:
- Ensures that attendees are prepared to discuss the most important product backlog items(PBI) and that PBIs have clear acceptance criteria. [1]
- Ensure UX designs are ready for sprint execution.
Collaborate with the team to establish a sprint goal. - Help the team understand the business value desired for the sprint. [1]
- Organize priority of features for next 2 sprints.
- Ensure that organization has properly allocated time/budget for team members.
- Work with the team to understand and plan technical debt reduction. Help set priority on essential bugs.
Developers checklist:
- Developers select stories for commitment in the sprint. The team(not leadership or product owner) must own the commitment to the content of the sprint.
- Understand team capacity for the sprint. Agile encourages a culture of sustainable pace and value creation. Regularly, the team should avoid working beyond their capacity.
- One of my favorite Scrum master trainers used to repeat the mantra “No mind works alone.” (Thanks Doug Shimp) With that in mind, teams show grow an ideal culture where teams work together to task/plan their work. The act of conversation around the acceptance criteria helps the team gain perspective on the work, tasks and their estimations.
- Define the definition of done
- Collect data/insight from past performance
- For each PBI, developers should create a plan to accomplish the story
- Each story task tends to be 1 day or less in size.
- If you’re planning a 2-week sprint, stop planning after 4 hours. If you’re planning a 1-month sprint, stop planning after 8 hours.
- In the sprint plan, ensure that you include process improvements from retrospective in your plan.
General Tips:
- Consider grooming the top of the backlog before sprint planning.
- Themes to plan during backlog grooming and sprint planning
- UI design
- Design
- Implementation
- Test
- Documentation activities
- Review release plans
- Encourage margin: Know the team capacity AND don’t fill it. Margin can empower the team to reduce technical debt, bugs, and elements that can not predict. The VS Code team tends to reserve a healthy percentage of capacity for documentation improvements, tech debt reduction, and unexpected stuff.
- Action over perfect plan: During sprint planning, the team attempts to forecast their commitment to creating an increment of value. In reality, agile teams recognize that change organically happens while making new stuff. On the tech side, you might discover that your small story becomes XL. As the team dives into a deeper level mid-sprint, the team and product owner might discover that a requirement does not make sense. With this in mind, encourage the team to avoid making a “sprint perfect plan.”
- Avoid capacity overflow: Say no to capacity overload!
- Use your architecture: Use your architecture layers as a checklist. To help you brainstorm tasks of a story, consider looking at a similar feature/architecture layout. You can often gain perspective of the work by thinking about your architecture layers or work that looks related.
- What services do you need to write?
- What kinds of infrastructure needs attention?
- Include time for unit tests or infrastructure tests
- What API’s are required?
- Check out the Steven Smith slides at the bottom of this post.
- Use the story acceptance criteria to craft your tasks. Let’s say the story has 3 bullets of stuff. You might allocate 3 tasks to each. I also tend to encourage teams to include tasks for design and developer smoke testing.
- Plan for testing using your definition of done
- Test automation(unit or integration)
- QA testing
- Peer reviews
We love to hear from our readers. If you have a cool tip for sprint planning with your teams, we’d love to learn from your experience.
Leave a Reply