Tomorrow is going to be the first offical sprint planning meeting for the team I am on at Trion. I’ve been doing Scrum since 2006, and I have facilitated a good many planning meetings. This time I’m not the ScrumMaster, but a developer — so it’ll be interesting to be in a different role.
The first sprint planning meeting is very important because it’s where the team will receive the first glimpse at the product vision. They also meet one another and establish a framework from which they will work with one another — a working agreement.
Working agreements help teams codify what the rules of conduct are. They can cover any variety of concerns from “No cell phones on ring during meetings,” to things like “Code is *done* when it has been peer reviewed, signed-off by QA and checked into the development branch.” These rules help the team manage expectations, especially through the storming phase and into the norming phase. It should be placed in a visible location near where the team is working.
A working agreement needs to be crafted and agreed to unanimously by the team (not management). Consensus is very important here, because people cannot claim later to not of been ‘on board’. The team should revisit the agreement during their retrospectives and decide if they want to add, modify or remove anything. Below is a real-life example working agreement from a highly productive Scrum team:
- Tell the Truth!
- Use the Impediment Backlog for blocking issues
- Address any issues to the correct party (at the right time)
- Meetings: be on time, end on time, have an agenda
- Communicate individual schedule
- Use sticky note on monitor, email, phone call, etc.
- Update backlog before SCRUM daily stand-up
- Be present for core hours: 10am to 5pm PST
- Communication – to the best of our ability
- Publish phone numbers and calendar
- SCRUM is at 11am PST
- If unavailable for SCRUM, communicate status
- TDD is a requirement for the project
- Pairing or code reviews are required for any shipped code
- When pairing turn off distractions (email, IM etc)
- Define and adhere to DONE criteria for stories
- Record accurate (actual) hours
- Define and adhere to version control rules
- Don’t break the build!
As you can see anything is fair game. Working agreements grow over time as the team unmasks issues and finds solutions. Having a punch-list of rules helps keep agreements fresh in memory so there is no reverting to bad habbits.
Trackbacks /
Pingbacks