It’s time to open the can of worms about duration of sprints or iterations. You will have people that swear up and down on the duration used. In my experience, almost two-thirds of the teams I have worked with over the past 10 years have utilized 2 week sprints. There is a certain psychology that exists with this timeframe with individuals, there are entrance and exit criteria that help set up a sprint for success, and there is also a cadence that becomes established that leads a company or product line to start looking at continuous deployment in a way that is possible with shorter durations. Let’s dive into them…
There is a law that exists, Parkinson’s, that suggests no matter how much time is provided to complete a set of tasks, the work will expand to fit the timeframe allotted. Looking at it in a much simpler fashion, 4 weeks… sure we can get that done. 3 weeks, sure we can get that done. 2 weeks, yes, we can get this done. 1 week…. Wait a second, you want us to do what in one week. Everything would have to go perfectly in order for it to be done in a week. Reality suggests using some type of cycle that seems reasonably long but also reasonably short allows for speed and accuracy on what is being completed.
The cadence a team then establishes by having a 2 week sprint helps to establish regular completion of work. It starts to have a team focus on what does it mean to complete a set of work within that timeframe. It helps individuals within a team start asking questions such as:
What do we need to understand this request?
Are there significant unknown factors that will derail our efforts?
What do we need to understand the full context of the request?
Oftentimes, this will lead to discussions around how requirements are elaborated. This will encourage a team to request items be broken into small enough chunks to be completed in the timeframe in question. Thinking very theoretically and applying it, Bill Wake’s INVEST acronym is heavily leveraged as well as thoughts from Jeff Patton’s "User Story Mapping" book. Horizontal slices of stories then become the focus instead of siloed approaches with front-end and back-end stories or other cross-sections (platform specific stories). Acceptance criteria then set the context as to what platforms, operating systems, mobile, web and other types of avenues are leveraged for the requirement to be successfully completed. After understanding what I oftentimes refer to as the “Entrance Criteria” or “Success Criteria” for a sprint, it becomes just as important to define the “Exit Criteria”.
This not only leverages acceptance tests against the acceptance criteria, but this should force a team to consider the level of technical excellence being employed to make the solution sustainable and repeatable wherever possible with manual intervention.
Finally, looking at establishing a cadence for completion and delivery becomes the backbone of success for a product and team. When criteria for entrance and exit from a sprint are set up, delivery then becomes the point of collaboration with the client or stakeholder. The 2 week sprint allows twice a month for a team to experience feedback loops with real client input. With this real client input, there are changes that can be made by the team to see how continuous delivery is possible or even needed for the purpose of the client in question. Remember, that just because everyone is trying to move to continuous deployment doesn’t necessarily mean that it needs to happen. This happens in many areas that we find out with a product that we can do certain things because it is cool or we think it would work the best. Make sure the question is not just being asked as to whether we can do something such as continuous deployment but whether we should be doing something like continuous deployment. This cadence when established allows feedback cycles to be leveraged by the Product Owner and team to be more successful as a result of what they are hearing. The shorter the cycle on a tangible change, the more regular feedback becomes.
Now, for everyone out there that says, there’s no way we can get that type of feedback from the real users or clientele of the product that is used. But, we can get it every 4 weeks. When push comes to shove, do what makes sense. It’s very possible that in making sure they are always present every 4 weeks and are able to give valuable feedback that they simply don’t know that feedback could be provided more regularly. Common sense should prevail. Good luck!