Planning ahead
Planning the stories and roadmap is usually prepared by the product owner and presented to the team to prep everyone on coming deliverables. Planning ahead means being able to anticipate some of the coming overheads such as holidays and company events that may affect the deliverable timeline.
Hence, having a roadmap of features that needs to be released helps the team to see the overall solution (can be weekly, monthly, quarterly). Here, I would like to emphasize to keep it simple. Often times, the most simplest of roadmaps with concise epic / themes on a quarterly basis is sufficient.
Example :
Sprint goals
For each sprint, there should be a clear and concise sprint goal that clearly defines what are the priorities of the stories. This provides a sense of purpose and direction to the team and also a focus on the activities in the sprint such as sprint demo and review.
The stories defined in the upcoming sprint are usually refined with the help of the team during backlog grooming. In sprint planning, any open ambiguous stories are checked and ensured to be clear so the developer can pick it up. The whole purpose of this is to allow the developers to build the product as effectively and efficiently as possible.
You can find more information in the links below :
- https://www.scrum.org/resources/blog/scrum-trenches-sprint-goal
- https://www.romanpichler.com/blog/effective-sprint-goals/
Story tracking
To ensure the team is delivering at the optimum level, scrum masters may glance through the stories that are in progress and provide support as well as helping to clear up any impediments that come up.
One of the most common questions I get from new joiners in the team is how do we know the progress of stories or how do we update the status of stories. Ensure that each story status is clear to the team members and when it needs to be updated. This is also dependent on the Definition of Done (DoD).
e.g. New –> Ready –> Work In Progress –> Resolved –> Ready for Testing –> Done
Once the above is defined and clear, there will be a sprint tracking board which lists all the stories by this statuses and can be filtered by each team member (somewhat similar to a Kanban board).
Most often than not, the approach is getting the different teams to sit together in a short session to clarify and iron out any understandings on the work that needs to be done.
This can range from technical, resource and occasionally business requirements.
Some of the practices include having shorter backlog refinement session (30 – 45 mins) every week with the objective to allow developers to review the stories and ask any questions clear off ambiguities.
From experience and observations, most often team members are not able to reciprocate on stories created by product owners during the first backlog grooming and hence, will need some time to digest, understand the new stories and ask questions for any clarifications in the following grooming sessions.
Alright, that’s it for now. Hope it has been helpful for you as it has been for me to share my experiences in scrum mastering 🙂
Disclaimer: What I am sharing is purely from my point of view and experience working with various teams as a scrum master. It does not reflect anyone else’s opinion or endorses a framework.
What I present in my posts doesn’t necessarily mean that it is applicable to your work, organization and culture but I am glad if it aids you in your agile journey.
Sincerely and with many thanks for reading my articles, Jason.
