Working Norms: Sprint Planning
Our working style also incorporates agile sprint planning.
We spent the first two weeks with our partners getting oriented, and doing free-form discovery; talking with folks, reading documents, reviewing previous research, trying to understand the problem space and organizational context, and getting situated.
We didnāt plan formal sprints; instead we created one Trello board for each week and added tasks as they emerged.
Halfway through this time, I learned about Sprint 0Ā from Cohort 2 #CodeForCanada PM fellow Siobhan.
Have you had any luck with Sprint 0? Is it useful?
Instead of Sprint 0, we used Sprint 1 to learn how to sprint as a team. We filled and prioritized the backlog, planned the sprint, updated and provided visibility throughout, and reviewed the sprint and did a retrospective together, continuously checking in with one another.
Although we did include substantial tasks, we were kind to ourselves if things were left incomplete.
Since then, weāve been on a bi-weekly sprint schedule. The sprint schedule goes as follows:
[Ongoing] Gather activities for the backlog
[Sprint Day 1 - Monday] Sprint planning meeting
[Daily] Standup at 9:45am
[Sprint Day 10 - Friday] Sprint retro
How do you organize your sprint planning meeting, daily standup, and sprint retro meeting? When do you schedule them? What format works best for your team?
We useĀ TrelloĀ to build the backlog and tee-up the sprint tasks. This has a simple and straightforward Kanban format ā backlog, todo, doing, done.
We tried a couple other Kanban mediums ā colourful sticky notes & sharpies and writing on a whiteboard.
Although these are great for in-office visibility, ultimately Trello is our source-of-truth because it enables remote work and is accessible on mobile.
What tools or software do you use for sprint planning and tracking?
Maintaining and prioritizing the backlog
Since weāre still in discovery, our backlog tasks have been exploratory and high-level. For example, āmap the policy landscapeā or ābuild a framework to prioritize problemsā.
I often refer to these as āchoose-your-own-adventureā activities. In almost all cases, the person who proposed the activity was accountable for ensuring it got done. They had the best idea of how to approach the activity ā whether it was individual research, a sticky-note workshop with the team, or setting up stakeholder interviews. But the approach became more visible as new information was uncovered.
Because these were mostly led by individuals, there hasnāt been much backlog maintenance or prioritization thus far.
At the beginning of a project, how do you balance your teamās excitement for individual initiatives and investigation, and prioritizing a backlog?
Change is inevitable. As our project progresses, weāll reassess what works and what doesnāt, and adapt from there.
As we move into experimentation, our activities will become more concrete in scope and tasks. Our tasks will likely have to be estimated and the backlog groomed; priorities clearly communicated to ensure the team is aligned and moving in the same direction.