Why are our Sprints so Crazy?
If Your Sprints are crazy, do any of these issues sound familiar?
- During Sprint Planning, it’s impossible for the team to break tasks into small enough chunks to be completed in a day
- QA gets scrunched at the end of the Sprint
- The team waits on design completion during the Sprint and cannot begin development tasks quick enough
- Late in the process (sometimes after the Sprint ends), it’s determined that what was built wasn’t actually the right solution
Is there sufficient team prep work?
It’s a common misconception that within Scrum, the team should only work on the current Sprint’s stories and nothing more. However, this approach leads to inefficiency. In reality, every team should spend time preparing for the next Sprint in order to maximize productivity.
To plan the story, the team needs to have a clear idea of what problem they are trying to solve and the boundaries on the scope. They need to work with the Product Owner, Stakeholders, Customers, and/or Users to better understand the focus of the upcoming stories. The team then works to refine the acceptance criteria to ensure it captures their understanding and assumptions of what is required by the story. This helps align expectations across all members of the team and with the folks requesting the story.
This can occur in full team discussions of the upcoming backlog with the Product Owner and Stakeholders, or with a couple members taking point to work through the details and then review with the team. Either way, all members of the team should possess a sufficient understanding of the business need.
Barely Sufficient Design
Once the clarity of the business intent is understood by the team, the focus turns to the solution. Some stories are small enough or don’t require substantial design making little impact if done during the Sprint, however others may require significant thought before unleashing the team for full planning or implementation. Typically, some activities (such as User Experience Design) occur before the beginning of the Sprint, so it’s available when tasking and the team isn’t blocked waiting on the UI Designer. This may also be required on a story that requires new Architecture decisions. If this activity is large enough, the team may need to break the story up so that it can be done incrementally. Perhaps do some prototyping work in one Sprint to prove out different technologies, followed by the final implementation story in a later Sprint. Or an incremental approach can be taken initially, avoiding the need to make a big up-front design decisions. (See Emergent Design).
Keep the goal in mind
How does this work in Practice?
Typically, a team should allocate 10% of their capacity to work ahead. This could be 10% of every team member or a more significant percentage for some folks (e.g. UX Designer, Architect). Every member of the team should be engaged in some capacity so it’s clear what the team is being asked to do as Sprint Planning begins.
The team should set up a forum with the Product Owner to review stories and acceptance criteria to flesh out details and find gaps. This could be a regularly scheduled meeting one week before the next Sprint. The Product Owner should provide the initial set of Acceptance Criteria, while the team also takes ownership to hammer out the rest of the details. If the responsibility stays solely on the Product Owner, the team may become blocked and won’t benefit.
For each story, the team should also determine if any pre-sprint design work needs to be done. If large enough, the team may need to create tasks for the current Sprint to have visibility into what needs to be done and who is doing it.
How does this solve our problems?
- Better understanding of requirements and solution will allow the team to have enough knowledge to task out the work sufficiently
- Since expectations are aligned between developers and QA up front, QA no longer has to wait until they get the code to figure out what they need to test
- Serial design processes are done prior to the Sprint so that work can begin immediately after the planning session
- Requirement details are worked out with stakeholders prior to development beginning