Planning and Executing Effective Agile Sprints
19 Jan 2013I’ve written previously on running better retrospectives in agile environments, in this post I’m going to pull back a level and share some thoughts on planning and executing the sprint itself.
Firstly, it’s important that each sprint is of a consistent duration (2 or 3 weeks has worked best in my experience, 1 week may work but require a very experienced team with often unrealistic focus — oftentimes this is not possible despite the best intentions of all involved) and has a steady resource allocation.
It’s well known that cohesive teams having spent time productively working together (meaning they’ve shipped software together) will almost always outperform a brand new team. This is why companies like Zappos and Google continue to invest significantly in the culture of their organizations, it’s not just lip service. Note, it’s certainly not just the big companies that place high importance on culture development.
The likelihood of a successful sprint increases dramatically when planning starts prior to Day 1. Personally, I’ve always preferred a 2 week sprint that starts on a Wednesday and completes on a Tuesday.
Important Dates
Day 1 .5-1h Sprint Kick-off
Day 6 1h Estimation Session (may be done in smaller groups)
Day 7 1h-2h Commitment Freeze + Test Day
Day 8 1h Sprint Planning for Next Sprint
Day 8-10 ?? Bug Fixing + Release Preparation + Next Sprint Design
Day 10 ?? Roll-in + Wrap-up + Retrospective
The reason to start/end mid-week is simple, it avoids the rush and panic that inevitably occurs when your sprint ends of a Friday. By targeting Tuesday, it gives the team a small break before coming back and putting 2 days of focused effort into getting software ready for a potential release.
In terms of meetings, they are unfortunately an inevitable consequence of team-based software development. Regardless of whether you’re doing scrum, lean, agile or some combination thereof, you need to spend time face-to-face ensuring that everyone’s on the same page and appropriate progress is being made.
The Sprint Kick-off is an opportunity for the team to get together first thing on Day 1 of a new sprint. The stories being pulled in to the sprint should not be a surprise to anyone and this session should be a final opportunity to weigh reality and commitments. Leave this meeting with a plan (identify the critical path, who’s on it, and what the milestones are).
The Estimation Session is an opportunity to meet and discuss up-coming stories in the backlog. It’s always a good sign if you have at least a rough estimate on all stories, at least a sprint ahead. Stories with large estimates warrant additional discussion, breakdown and re-estimation before even being considered appropriate for sprint commitment.
The Test Day (or what the hell is going to be ready to ship next week) is the target for developers to lock down their feature sets and changes. If your environment is conducive to test days (essentially getting the team focused on manually walkthrough changed aspects of the software for 1-2hr) then they’re worthwhile. The test day certainly does not replace automated unit, integration and even regression tests… they more address the almost certainty that not all aspects of an application can be adequately automated.
It’s worthwhile noting that the Test Day will almost always identify bugs or necessary enhancements. These must be prioritized, and often may result in lower priority tasks (that aren’t done) being moved to the next sprint. The reason why we do all-hands testing on Day 7, is that it provides 2 or 3 days of time to address issues prior to release.
The Sprint Planning session occurs on the Friday after Test Day and ideally a few days before the planned sprint completion date. By occurring after test / commitment day, you have an indication of how much effort is remaining and what may need to slide to the following sprint.
The final couple days in a sprint should be spent on polish and bug fixes. If there are large stories in the subsequent sprint, considering finding time to do more detailed design, breakdown and more granular estimation. At times, I’ve seen various rules around the maximum size of taskable work, say no tasks larger than 2 or 3 days are worked on. Every team is different, but I’ve seen this be successful.
However avoid falling into the trap of tasks that look like “Implement XYZ”, “Test XYZ”. They are one and the same, and I’m sorry, but an implementation task is not completed until it’s tested. Depending on system complexity, splitting out a small task targeted at regression testing may be allowable at times.
Lastly, the Sprint Retrospective is a critical opportunity for the team to reflect on their past two weeks of effort. See my previous post for some thoughts on effective retrospectives. TL;DR: Retrospectives must be focused, and action items must be written down and made front and center throughout subsequent sprints. Give them a spot on your white board and visually track progress against them.
IMO, you should be able to run productive sprints without feeling like you spent half of it in a meeting room. Aiming for < 2 or 3hrs of meetings a week would be spectacular.
What Happens Each Day
Daily stand ups. Nothing major just avoid just retelling what you did yesterday. Individually, we should know how close to completion we are and whether our milestones are on-track. If things aren’t on-track or you need help, bring it up and have a discussion about it after the stand-up.
If tasks aren’t moving across the board (not-started -> in-progress -> done / qa’d -> ready for release), discuss it. By keeping tasks to no more than 2 or 3 days, you should see tasks movement almost every day. This is critically important for the team lead or manager to stay on top of, it’s ultimately their responsibility to ensure that the teams commitments are being delivered.
Adaptations
There are many different ways to modify the timeline I’ve outlined above, with the most obvious being to extend it to 3 weeks.
With a longer sprint, you’ll need to invest a little more time in sprint planning and estimation. Simply to account for the increased amount of work being committed to in 3 vs. 2 weeks.
It’s also important to consider the time of day that meetings are held (including stand-ups). Involve your team and figure something out that isn’t going to adversely impact productivity or morale. Consider meeting free afternoons (or mornings) to eliminate unnecessary context switches.
That’s it for now.
Feel free to follow me on twitter, @ajordens. I’d love to hear feedback and what’s worked for you. Let’s continue the conversation.