Working Norms: Sprint Planning
Our working style also incorporates agile sprint planning.
The first two weeks
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.
Sprint planning schedule
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?
Sprint planning tools
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?
Looking forward
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.













