I attended the “Are We Done Yet?” meetup of the DC Scrum Users Group last night. @RichardKCheng did a good job as the trainer. His slides are available as a PDF.
The Team Charter is the team’s self-realized, self-authored norms for how they work, unlike the Project Charter that is handed down from on-high. This includes things like the schedule, definition of done, project understanding, and team rules. There’s no reason I can’t write one up for our team tomorrow.
Some of the stories told and questions ask definitely point to other teams needing a Team Charter more than my team does. We’re already on board with timeliness and professionalism, and we have a decent Definition of Done. Even so, it certainly won’t hurt. Rules for ending horseplay, being available during core hours, and paying attention during meetings are only necessary where the team doesn’t already do these things.
For the “Definition of Done” and “Definition of Ready” themselves, Richard spoke to defining these at various levels:
- Ready to Start
- Project Backlog Item (PBI)
The “Definition of Ready” is essentially the “Definition of Done” for “Getting a User Story/Requirement Ready.” The backlog should be prioritized and refined before Sprint Planning occurs so that there is a supply of PBIs that are Ready. Richard recommended having a refinement meeting several days before Sprint Planning and then having a developer review the PBIs help get to this Ready state.
One of the key recommendations of the night, which should be obvious once you understand the principles of short feedback loops is that the more things you put off doing until the Release level, the greater your risk of failure. As much as you can while being efficient, move activities from the Release level to the Sprint level, and from the Sprint level to the PBI level.
Maybe security scans are onerous and time-consuming, but there could be ways of running part of the scan every Sprint, which thus gives the team the opportunity to address the findings much earlier.
While multiple weeks of regression testing can’t, by definition, be performed every two weeks, creating automated tests (i.e. Coded UI Tests) can permit you to get much of the value at the Sprint or even the PBI level. Why not run the automated tests after every check-in?
All in all, a good meetup, but mostly a confirmation of what I suspected.