| layout | keywords | comments | title | description | <!-- author | micro_nav | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
default |
false |
Product Team Rituals |
Follow this simple framework and you will have the energy to strategise about the future of the product. |
|
true |
Below is a list of team rituals that are beneficial for running a development team.
...
....
NB: If you're kicking off a new project then read the project brief + project kickoff play first
Make sure your quarterly roadmap is up to date and you have broken it down into smaller product or experiment briefs
👉 Review the backlog and prioritise the user stories based on urgency.
Populate the backlog: At this stage the user story only needs to describe the feature in broad brush strokes
Refining the backlog: Fleshing the stories out. Refine the backlog with, as a minimum, the ‘Three Amigos’ – the Product Owner, a developer and a (UX) designer.
Pro tip: Backlog refining can be done as part of the discover track in Dual-track scrum
Send email digest of the previous week to our team and advisors.
One of the biggest benefits of documenting each week is it provides a history that new hires can browse at their leisure to get a better understanding of how the team got to the present.
- Dev sprint wrap-up/kick-off: Depending on the week (we work in two week sprints), I’ll provide a brief overview into what work we just delivered or just started working on.
- If you manage more teams you can add separate updated for those, e.g growth/marketing, Sales, PR
- The rundown: Any day to day activity or updates that fall outside of sprint work. Dave, my partner and CEO also includes detailed notes on the following areas:
- Growth
- Fundraising
- Hiring
-
Customer feedback: This is a great way to keep the team up-to-date on what is and isn’t working with the product.
-
Upcoming milestones: Bullet list of growth and roadmap milestones
-
What are we reading: We keep a #reading-list Slack channel. If anything pops up there that’s worth an extra look, it gets captured here as well.
Pro Tip: for more details about weekly recaps, read the six templates for product managers
At 4:30pm, Our slack plugin sends a message to the #stand-up channel and the team updates everyone on their accomplishments for the day and focus for tomorrow. This allows us to share links to mockups or tickets we are working on and gives the team time to process blocking issues more easily.
- Today: A list of what you got done today.
- Tomorrow: A list of what you plan to work on tomorrow.
- Blocking: A list of blocking issues and @-replies to anyone who can help
The objective of the Backlog refinement meeting or Grooming session is to get enough of the product backlog ready to comfortably populate the next sprint backlog.
Backlog refinement is used to refine the items at the top of the backlog: Break them up into user stories that can be tackled in a single sprint, agree on acceptance criteria for those stories and, often, to estimate them (normally by attributing story points).
Estimating stories: Planning poker to come! :)
Figure out how we actually do the work and agree the order we’ll work on it.
- The whole team is required for sprint planning. It’s an opportunity to talk through the tasks required, challenge any previous assumptions, including estimates, and check that stories and acceptance criteria are really Ready for development.
- It should be time boxed so that it doesn’t eat into the time needed for actually working on tasks. For a team working in 2 week sprints, expect planning to be no more than 4 hours.
Agree on the sprint backlog: Allocate tokens (e.g. poker chips or matches) to each team member to represent the number of hours they have available in the sprint.
The sprint goal: The sprint goal is set by the PO and is a short encapsulation of what the team has agreed to achieve during the sprint. Examples: Build a responsive homepage with navigation menu and Twitter feed.
The sprint demo is invaluable for keeping stakeholders up to speed with the progress of product development. It allows them to feedback and suggest improvements that can added to the product backlog to maximise value.
While demoing the sprint work, user stories provide a good framework to report on which work has been done and what remains to be done.
A standard SCRUM sprint is two weeks with one or more release. Sticking to a template will allow you to work faster and more efficient.
- tl;dr: Sometimes readers just want a quick summary.
- Released: A more detailed explanation of each feature, where to find it, how to use it, etc.
- Fixed/Updated: If bugs are part of the release, quick and to-the-point notes are essential to communicate.
Run a retrospective at the end of a sprint. It is a forum for the team to come together and discuss successes, failures, learnings, and note down anything that will be useful in the future. It's a cathartic exercise designed to help teams and companies continuously learn and improve.
NB It's worth nothing that retrospectives are not an appropriate platform for personal feedback. This should be done separately in one-to-one sessions.
Continue: Things that went well
-
What went well? Why did it go well? How do we keep encouraging that?
Stop: Things that didn't go so well
-
What went badly? Why did it go badly? How do we avoid repeating that?
Start:
- What should we start doing?