I was asked by a colleague how we have designed our software sprint cycle. As I explained it, I thought that this might be a good topic to just outline as part of this blog. This approach, which could be dubbed “lucky 13”, is the standard of how we conduct product work. Is it perfect, probably not, however, we do see it as an experiment and evaluate its effectiveness over time.
Some precursory notions as to why we built our sprint cycle this way:
- We want to be reasonable and responsible in how we build software and give a predictable horizon for commitment delivery to the product owners.
- We want to give the proper space for planning, tasking, review and retrospective
- Continuous learning is highly important to me and our organization so it was with intention that we built in slack time to allow us to do this.
So how does it work?
Day 1: Planning and Tasking the Work Ahead
This is our planning and tasking day. We split it into portions to allow the conversations to occur so that we can gain understanding and make our commitments as well as use the second half of the day to decompose the work ahead.
Days 2-11: Product Build/Test/Deploy
Composed of 10 working days for building, testing and deploying our code to meet the commitment and prepare to review for the product owner. 15 minute daily standups are held throughout this cycle to synchronize the team work.
Day 12: Review and Retrospective
Typically our product review occurs in the morning allowing us to demonstrate the features for the product owner. We will, on occasion, have a window for sizing any new stories that have emerged into the product backlog. Following lunch (usually as a team) the team meets in the afternoon to conduct their retrospective. While many of our retrospectives focus on improvement in the next cycle, we often times balance this with focus on team unity, team health and technical discussion as needed and to keep the retrospectives fresh and engaging.
Day 13: Lab Day
This is the slack that we build into our schedule for continuous improvement. It’s a very small horizon so deep work is unlikely to occur. Teams spend this time learning new skills through online training, have more “deep dive” technical discussions or discuss refactoring that may be needed as a result of accrued debt within the cycle. This point in the horizon accomplishes two important things. 1) It allows teams a moment to reflect on their skills, their product and seek to learn as a part of the culture. 2) It gives the team a momentary “breath” between sprint cycles. It allows them to level set, focus and be prepared for the next sprint
How we Adjust Capacity
We made a conscious effort to really consider team impacts and after observation we determined that our team impacts to capacity occur in two major forms; team capacity loss and team member capacity loss. We handle each of these differently.
Team Capacity Loss
If the entire team is impacted, by a conference, a holiday or an “act of God” disaster, we consciously adjust our schedule to account for this impact to allow the team to retain a full 10 day build cycle. This does not happen very often but we found that it is best for us as it retains consistency within our development cycle.
Team Member Capacity Loss
This is handled differently based upon the reason behind the impact. If a team member has a planned outage (vacation, doctor’s appointments, etc) then we adjust the capacity for the individual based on the outage and the team adjusts their commitment accordingly to compensate for this team member being out. They communicate about this prior to the next planning meeting so they can make this impact visible to the product owner.
If the team member has an unexpected capacity reduction such as sickness or other life trauma; the team uses the idea of “first responsible moment” to make this impact visible and communicate impact to the commitment to the product owner. It has become generally accepted in our organizational culture that in doing this, they provide insight as soon as they are aware of impact which builds trust and openness between the teams and product owners. It also provides the product owner an opportunity in the face of impact to have a conversation with the team to determine if any value can be salvaged from the commitment impact and provides them insight early to review release plans and manage stakeholders.
Pros and Cons of this Cycle
- It provides a given horizon for the teams and the product owners.
- It allows the teams to control and adjust the work based on impact. It reinforces the agile values of self-organization, self-management as well as transparency.
- It gives team space to ask questions before beginning a sprint cycle in a larger context before commitment to create shared understanding or if necessary split stories, etc.
- Through building in slack time within the standard sprint cycle, we foster the value of learning and provide the space to do this on a regular basis.It also allows for team building and to “level set” for the next sprint.
- For our organization, this sprint cycle appears to be a “sweet spot” of predictability and maintaining a small enough horizon to effectively manage risk.
- Using such a long cycle only allows roughly two sprint cycles per month.
- The horizon of the “lab day” is very small in scope and therefore no in-depth learning can occur.
- I have been challenged by purists that this is not a typical scrum sprint cycle as I have purposefully pushed the beginning and ending “rituals” outside of what people think the sprint should be. What we discovered was that the teams sought more time to prepare for the work and therefore made a conscious effort to give them this space. We also felt that the review and retrospective should have its own horizon for effectiveness. I do think we are following the base scrum guidance of a sprint being 1-4 weeks and performing the rituals prescribed. We just feel that they needed more focus outside of delivery to heighten effectiveness.
- This cycle relies a lot on emergent design from both an architectural and product design sense. Finding ways to place this better into the context of product planning so the team could have wireframes and user experience for guidance (and refine during the sprint) as well as base architectural guidance would be helpful. We are presently evaluating how to best facilitate this.
So, this is how we build products at my company and what has worked for us. This may not be the end result of where we land but we’ve been using this approach effectively over the past 2-3 years. As most everything we do, we see this as an experiment, open for refactoring, destruction or re-envisioning. The process doesn’t make us special, it’s the people and the fact that we know that the process just helps keep us on the rails.