Meetings
An overview of the types of meetings we find useful.
Project Kickoff
The Project Brief
Create a project brief that describes everything that the team will need to get started. This is a place to collect everything we know about a project before it starts. It’s intended to be a document that we can share with our client, but we shouldn’t expect that they are required to read it or add to it. We should keep it up-to-date as we learn more. When new folks join a project, it can provide a quick overview and answer some obvious questions. Note that the act of creating the brief, and gathering together all the information that it contains, is probably more valuable than the document itself!
Get together
Share what’s known about the project, including what was in the project brief. Could include details on tech stack, repos, branding, product vision, competitors, or anything else that will help us make the product.
Might be a part of a fuller Boltmade Foundation Sprint in which we do a deep dive with the client to identify users, scenarios, and to create a user story map. These things are used as a starting point to drive design and to form the basis of a development backlog.
Need to agree on how to manage the backlog for the product, and what tools to use. It might take a little time (days or even weeks) to land on a workable relationship.
Milestone Planning
Work with the product owner to identify the themes for the next 4–6 sprints and, roughly, what should get done. What gets done in an individual sprint will be identified during sprint planning each week.
Milestone planning happens several times during the course of a project.
Commonly, a MILESTONES.md artifact will be created from these meetings.
Sprints
We iterate through a project in one-week sprints. Sprints keep us accountable to our clients on a weekly basis, and give us a chance to course correct when problems arise.
Sprint planning
The team and/or the product owner constructs a sprint backlog based on product owner priorities. This backlog often contains work that could occupy the team for multiple sprints.
To start off each sprint, the team decides what they believe can accomplished during the sprint from the top of the backlog. The product owner can make last minute changes to the order of the backlog, but the team decides how much goes into the sprint. Whatever the team picks is what the team is committing to getting done before the next sprint planning meeting.
Sprint demo
At the end of the sprint, show the client (product owner) what got done. Do a little prep and tell it as a story, rather than treating it as a checklist to be processed. Ideally, the product owner agrees that things got done and each issue is closed. Or, perhaps there are problems. Or, perhaps the product owner has an idea of how to make it better, and that improvement gets added into the planning backlog. It’s best to not get bogged down in long discussions, though.
Sprint retrospective
Reflect back on what worked and what didn’t work in the sprint. Figure out what could be changed to make sprints more effective. If we miss sprint commitments we need to reflect on that and understand why it happened (for example, a promised API was not made available) so that we can agree as a team what can be done to avoid the same issues in future sprints (or why it might be the case that we can’t, if the risk remains).
A method of running these meetings that we are fond of involves passing around stickies, and setting up 5 distinct categories:
- Stop Doing
- Do Less
- Keep
- Do More
- Start Doing
Everyone gets 2–5 minutes (based on what makes sense for the team), alone, with their stickies to write down as much as they can think of for all the categories. Everyone must prepare at least 1 sticky. At the end of the time limit, all the stickies are collected, placed under the categories, and the team can have a discussion about what came up. At the end of all of this, the team should reflect back on their previous goal, and pick a new 1 thing to improve upon or keep doing.
Commonly, a RETROS.md artifact will be created from these meetings.
These things are easy to write, but not always easy to do well!