Scrum – Product Backlog
Before anything, a team needs to have something to work on. A team consists of the Product Manager and Developers. You might also need a scrum master to help coordinate and facilitate the whole process. Instead of having a detailed execution plan, proper management should have a mission or a high-level direction to work on. Trust the team and let the team iron out details. A good mission reduces the need to micro-manage and let the team has more autonomy to change or pivot if things have gone wrong.
Next, PM begins by creating a game plan on how to execute the mission. Studying user feedback or market, and convert it into an idea or feature for the team to work on. Depending on the scope, start by creating tickets (tasks or stories) and put them into the backlog. Try to get into as detail or granular as possible. If you aren’t able to breakdown the technical details, don’t fret as we will have other rituals for the engineer to break down later.
Building the Story
A story is a summary of the work that needs to be done consist of Who, What, and Why. In summary use this template.
As a {Who}, I want to {what} because {why}
Work out the acceptance criteria as well. This will ease the developer to know what is included in the scope of the ticket. Eg. What the UI looks like, business logic, type of test, etc.
Negotiate the Definition of Ready and Done
DoR is when the ticket has enough detail for the team to begin work on. In another word, the criteria where the ticket can be accepted by the developer.
- I – Independent (loosely couple, for estimation)
- N – Negotiable (what & why is define, how to nego)
- V – Value (Should deliver value)
- E – Estimable (Size and cost)
- S – Small enough
- T – Enough detail to test
DoD on the hand is the agreement of where the tasks and ticket that is assigned consider being complete. In another work, the criteria where the work is accepted back by the PM and stakeholder.
- Most of the time is what is agreed on in the acceptance criteria.
- Some may consider including until is release to prod only to be consider Done.
Grooming
This is where the subsequence details of the ticket are beginning to align and workout with the team.
Here the team will add the necessary details such as subtask, spike, or foresee blocker that can unblock (eg, access or procuring service or tool).
Besides that, they also need to estimate the ticket size (if possible into a release planning) and prioritize accordingly such that we can work on the story that follows the level of importance. And, most important the sequence that makes sense. Eg, developing the backend API or mock API before starting to build the frontend.