In the previous article, you’ll find a tactic for relative storing sizing.
Grooming and planning are done and now it’s time to Sprint. How do we keep everyone working towards the goal and not stepping on each other’s toes? This article focuses on the Sprint.
- Setup the Sprint board
- Daily Standups
- Definition of Done
Setup the Sprint Board
Once all the tasks are defined for all the stories in the current Sprint, the Sprint can begin. Contributors assign tasks to themselves, with a Work-In-Progress (WIP) constraint of 1. It should be very clear who is working on what tasks, to avoid duplication; wasted work. If you are using an analog board, you can pin a name tag of the contributor to the task they are working on.
I’d highly recommend using notecards and a big pin board. If each story is written on a notecard and each task on it’s own notecard, you can line them all up on a pin board with tacks. Use colored tacks to indicate statues. For example:
- Not started (clear)
- In progress – assigned to _ (still clear, but with name tag of person working it)
- Started/Stalled – not assigned (yellow)
- Blocked (red)
- Done (green)
The yellow and red pins are unusual and require discussion in the Daily Stand Up.
The name tag system on a pin board works good. We call this analog, because it’s not digital. Any team member can glance at the board and immediately see what’s done and whats not and who is working on what. Analog works great for small teams all working in the same room.
When you have remote team members, electronic sprint boards may work better. If you use electronic, the goal is the same: everyone knows what’s done, what’s not, and who’s working on what, all in a quick glance. As long as you can accomplish that, the electronic board should work fine.
Definition of Done
Definition of Done is a check list of items that are assumed to be completed before calling a Story done. These items are often givens, like “is deployed to production”. You’d be surprised how many times these items are overlooked. Having a check list ensures a common understanding of what “done” means.
For web application software, here is a list of common DoD items. For other industries, the DoD will certainly differ, and will differ from team to team anyway.
- Unit test coverage greater than 90%
- Unit tests cover both positive and negative cases
- New integration test written and passing
- Support documentation written and approved
- All acceptance criteria is satisfied
- Deployed
- Seen and accepted by the PO
Brainstorm with the team to come up with the initial DoD checklist and pin it to the board. Anytime a story is marked done, go over the check list, as a team and ask about each item. It may seem obnoxious, but consider the consequences when something is accidentally skipped.
Imagine getting on an airplane and the pilot says, “never mind the pre-flight checklist, let’s take off.” Would you prefer the pre-flight checklist be consulted every time, just to be on the safe side? If you need more convincing of the importance of the checklist, read The Checklist Manifesto.
Note: Some stories don’t fit the DoD mold, because the nature of the work may be non-standard. In software development, most stories are features that require writing software that needs to be tested, documentation written and deployed. However, some stories aren’t product features. For example, “Update the Jenkins build pipeline to conform with new company standards”. The DoD checklist covers the most common stories, not these unusual maintenance stories. It’s okay to have more items on the checklist than would apply to every story too. An “n/a” answer to a checklist items is fine. If in doubt, add it to the checklist.
Daily Stand Ups
These are very short daily team meetings, 15 minutes at most. It’s a quick alignment to put everybody on the same page. I’d recommend doing it first thing in the morning to start the day, but it’s more important to pick a time that all team members are available. Ask each person to state: what did you do since last standup, what are you going to do today, and do you have any blockers? Do this in front of the Scrum board, so everyone is looking at the board while the statuses are being stated. The visual aide of the board helps keep everyone well informed of the status of the Sprint.
Finish with the SM giving a quick assessment of the Sprint, after hearing everyone’s account of current status. For example, “We’re tracking well for this Sprint and I see no reason we won’t finish. Have a great day and let me know if you need anything.” or “The ‘blah’ story appears to be at risk of not finishing, I’ll update the PO on the risk and come up with a contingency plan by tomorrow.”
Don’t let anybody ramble in the daily stand up. If a more in depth discussion is needed, state that you’d like to discuss in more depth right after stand up. This allows un-impacted team members to get to work.
In the next article, a discussion about how long a Sprint should be, one week or two weeks?