Transcript of "Agile Scrum Sprint Length: What’s Right for You?"
• Cognizant 20-20 InsightsAgile Scrum Sprint Length:What’s Right for You? Executive Summary perform design, development and testing within a shorter period and produce a quality product. When a team begins a project using the Scrum approach, one of the first questions that often Their thinking is, if they have more time, they arises is, “how long should our sprints be?” After will be able to accomplish what they commit to. the collective team understands what a sprint is For teams new to Scrum, there might be reasons and how Scrum works, several discussions on the for choosing a longer duration. Perhaps they topic usually ensue. would like some padding, or they lack confidence in their ability to deliver in a shorter amount of In this white paper, we’ll review the purpose of the time. Perhaps they are not sufficiently insulated Scrum timebox, the reason why two weeks has from the enterprise and have many dependencies become the industry standard and some consid- on outside teams that cannot respond quickly. erations for when another timebox may be appro- (“The DBAs have a 36-hour SLA, so we’ll need to priate for your particular situation. wait…”) Timebox Duration Considerations Whatever their reasoning, let’s review the Teams new to Scrum struggle with questions of variables and consequences driving the decision. duration and expectations of what can be accom- The Measuring Checkpoint plished in a Scrum sprint. Typical questions often Sprints in Scrum are unchangeable timeboxes arise: “How long should it be? How can you expect that provide the team with a “measuring check- me to get all that done in that short amount of point” for gathering information about progress time? How do we know we’ve chosen the right and making adjustments to scope, staffing, fore- length?” casts, etc. With this purpose, the more frequent You will hear Scrum experts say that a sprint can the checkpoint, the more often metrics are vary from one to four weeks, depending upon the gathered and the faster the cycle time for project and the team members involved. What’s the team to inspect and make adjustments, appropriate for your project? leading to a more efficient process more quickly (e.g., do they need a DBA to join the team?). Based In Scrum development, it’s common for new teams on what the team has accomplished, how should to pick a timebox at the longer end of the scale the release plan (the forecast) be updated? What because they don’t understand how they could can management do to help the team achieve cognizant 20-20 insights | april 2011
a faster velocity? Note that this checkpoint room without a cost is a “false truth.” Indeed, has nothing to do with the type of project or the it may provide breathing room at the cost of amount of work the team chooses to commit team velocity. Consider the time change during to. Also, for a large company’s projects where a Daylight Saving Time, when people actually have project management office must be included, this one day a year with 25 hours. How do they spend provides the PMO and leadership with business their “extra” hour? Some may choose to work intelligence data from which they can help the more, others may choose to sleep or rest more, team accomplish its goals. and others may choose to do more. The point of this simple analogy is that people will adjust to fill The Sprint Review (a.k.a. Demo) whatever time they have been given. The sprint review meeting provides an opportu- nity for the team to hear feedback from product We postulate that the smaller the sprint duration, owners, peers and anyone else who attends. The the faster the engine can run. Smaller durations more often a sprint review squeeze out the fat and can only run lean. Consider that if the team knows it has up to three weeks Not unlike the fixed occurs, the more often feed- to perform a task, it may spend time researching back can be provided, incre- political timebox of mentally improving the a better solution than its “first thought” design. U.S. elections, the product. If this occurs on a However, if the team only has one week, it must quickly implement what can be accomplished in retrospective may shorter cycle time, the cumu- the sprint. lative effort of the smallbe used as an outlet improvements resulting from for individuals’ a series of frequently held The Commitment An argument for shorter duration sprints is theprocess frustrations, reviews will yield a better issue of how the team handles the absence of a product than that of a longer not necessarily to cycle time. In fact, late in key team member. Regardless of the reason for vote anyone out of a project, the team may the absence, the general rule is that the team acts as a unit and must pick up the slack to meet office, but to allow wish to consider a move to its commitment. This places a significant burden one-week sprints to increase people to voice the opportunities for feed- on the remaining team members for the duration their opinion. back as it prepares for a of the sprint once the absence begins. In longer production release. duration sprints, the team has committed sub- stantially more points than a shorter duration The Retrospective sprint, and if a person is out for a portion of The retrospective is a key aspect of the inspect- that longer sprint, the remaining team members and-adapt Scrum cycle. The more often a team must either carry the load longer before they pauses to consider how to streamline its process, can resize velocity or de-scope items to which the sooner it will identify process issues, attempt they’ve committed. We’ve found that, in shorter to address them and reach terminal velocity. duration sprints, when a team member is absent, Frequent process improve- teams are more likely to complete the sprint with Smaller durations ment meetings also allow for the original scope than de-scope it. The reason: a team to provide feedback to Teams can “endure pain” for a few days. squeeze out the management on productivity fat and can only drags, such as spending time The Unbroken Think-Stream run lean. creating status reports that One consideration for longer duration sprints is no one will use or creating that software development is, to some degree, a business requirements document that no one more art than science, and it requires a level of will read. Not unlike the fixed political timebox of creativity that cannot be rushed. Certainly, it U.S. elections, the retrospective may be used as seems obvious that if the team performs one-week an outlet for individuals’ process frustrations, not sprints, it has only three actual work days — the necessarily to vote anyone out of office, but to first day is spent planning and designing, and the allow people to voice their opinion. last day is spent on the review and retrospective. On longer sprint durations, say four weeks, the Sprint Planning team has 18 unbroken days for the team think- The perception that moving to longer duration stream. They have time to dream, be creative, sprints will reduce pressure and provide breathing identify high-risk design issues and address them, cognizant 20-20 insights 2
toss out their first or even second version of an encountered in the course of developing aidea and restart again and again before bringing component, they put all their energy into solvingtheir ultimate idea to the sprint review. This it. In this scenario, one possible path has beendegree of creativity and the pursuit of perfection taken many times by developers. The developerare not to be found in deadline-driven software becomes consumed by thedevelopment. challenge and doesn’t report it Another as a block to her Scrum master; consideration forHuman Nature and Reality after all, she’s smart and, in theThe boots-on-the-ground reality is that the past, has solved more “hairy” longer durationsame thing is going to happen at the end of the challenges than this one. sprints is the timethree-week iteration that happens at the end of The catch is that, in a short-dura- it takes to flesh-outa one- or two-week iteration: Time allocated fortesting and preparing for the sprint review will tion sprint cycle, the challenge an epic into a familybe squeezed. What we’ve found is that it’s more must become visible to the Scrum of fully developed master. This is against the devel-a matter of the team adjusting what it can do oper’s nature — she doesn’t want stories and documentduring the iteration duration and setting expec-tations appropriately among themselves than to bother the Scrum master with the subtasksthe alternative, which is trying to lengthen the a “non-issue.” So, what happens? for each.iteration so the team can finish the stories they Often, the developer works tocommitted to. The “better” solution to this point solve the challenge right up to the deadline butis to reduce the amount committed to, break the fails to finish it per the acceptance criteria, andstories into smaller tasks, pick up more stories the product owner is surprised that the func-opportunistically, deliver functionality earlier in tionality was not completed in the sprint review.the iteration and allocate time to test and prepare There is a danger here; if this behavior occurs infor the sprint review from the start. the context of a longer sprint duration, the oppor- tunity cost will be quantified in the form of lowerProcrastination velocity.One aspect of human nature is for people topostpone and procrastinate on work that they know The Story Creation Debaclethey need to do. While this must have a scientific Another consideration for longer duration sprintsname, let’s affectionately call it “college term- is the time it takes to flesh-out an epic into apaper” thinking. Why? The stereotypical college family of fully developed stories and documentstudent who is assigned a research paper at the the subtasks for each. The reality is that somestart of a semester will think he doesn’t need to topics require lots of time from the subjectstart on it right away; the end of the semester (or matter experts and may need several “reviews”“term”) is many weeks away. He does other things with the product owner, his peers or other stakeholders before theand comes back to it about three weeks before it’s A better approach isdue, only to realize that he is going to need more acceptance criteria for a familyhours than are left to produce a good paper. His of stories is ready for developers to extend the time toprocrastination will result in a lower quality paper, and testers to start translating create that family of that story into functionality.with less content or depth on the topic assigned. stories across sprintsThe same may happen with a Scrum team with This is where we need to and provide updatesa longer duration sprint. It may not “feel” like a recognize that it will take time to at the end of eachsprint if the duration is four weeks. Instead of draft, socialize and refine storiesdiligently using the unbroken time for a think- as the team moves through the sprint as to wherestream and following a rapid creative-destruc- story creation process, and we the group is intion cycle, the team slowly starts on the stories, should forecast upfront that a the process.building on its previous sprints’ work but realizing particular family of stories willwith only a few days left that what it’s built is not need more than one sprint to complete. For someadequate. stories, three weeks won’t be enough. In previous projects, we’ve found that some story families canVisibility into Team Challenges take up to eight weeks to produce because of theProfessional developers are smart translators subject matter experts and/or the complex naturethat like to solve puzzles. In the mindset of a of the topic. With that said, it is not wise to movestereotypical developer, when a challenge is the sprint review, retrospective and “metrics cognizant 20-20 insights 3
gathering checkpoint” just because a “story story, that means it will complete 10 fewer storiesauthor” team member needs more time to finish over a six-week period. That represents a signifi-a family of stories. A better approach is to extend cant difference in functionality. A product ownerthe time to create that family of stories across would probably balk upon hearing that news.sprints and provide updates at the end of eachsprint as to where the group is in the process. In a baseball analogy, the difference between an average hitter and a great hitter is only oneAnother approach is to establish a checkpoint additional hit per week. If a team can do thewith one or more business “peer reviewers” that same — that is, commit to one additional storywould verify that a story is ready for development. per week — it will raise the bar and complete theThis validation step could also act as a measure- project with a much better product than what anment checkpoint for the rate of story creation, “average” team would have produced.which would provide one more data point formanagement and the team to understand its Should the team keep up the pressure, it mayvelocity and productivity. be able to produce the same as it would in the two-week sprints, but it is unlikely it will exceedSome Metrics to Consider that. In other words, on this point, there’s littleLet’s assume for a moment that your Scrum upside to switching to three weeks but a signifi-team is struggling through two-week sprints but cant potential on the downside.is able to produce 100 story points of velocityfor each sprint. They are struggling because of Two Weeks: The Standard?pressure to complete the stories to which they The two-week sprint duration (10 business days)committed, but they’re not working weekends to has become the de facto industry standard.complete them. However, the testing activities Why?are squeezed, and the team doesn’t feel it has theproper time to prepare for the sprint review. At The two-week sprint has the best balance of all theone sprint retrospective, a member proposes that above factors. It allows for a team to have a smallthe team switch to three-week sprints to reduce amount of creativity with eight days of unbrokenthe pressure, perform appropriate testing and think-stream, and it provides a near-term deadlineprepare for the sprint review. The real issue is that kills procrastination and forces developers’that the team is committing to deliver too many challenges to the surface more quickly. Moreover,stories in one sprint, and they need to adjust the this approach is often enough to gather feedbacknumber downwards. However, let’s consider this from the sprint review and reflect on the process.proposal from a simple metrics perspective. Finally, it sets a pace for measuring checkpoints twice a month (leadership usually likes that),We suggest that moving to three-week sprints keeps the pressure up and “feels” like a sprint.does not actually solve the underlying issue. Ourrationale: It is false to extrapolate that the team What’s right for your project? That’s a decisionwill now average 150 points in the new three-week you’ll need to make. Perhaps you are in a situationsprints. Typically, the team will drop back a little where your team members lack experience orbecause it perceives that the pressure is less, say a key skill in a particular area, or your team isto 130 points in the three-week sprint. The team struggling with breaking down the stories intomay now “feel” it has breathing room, but it was tasks, and you conclude that two weeks is just toobought with a 13% reduction in throughput. short. (For a summary of various sprint lengths and their challenges, see Figure 1.)In terms of velocity capital over a six-week period,if the team could average 300 points across The key with longer duration sprints is makingthree two-week iterations, and if they move to them “feel” like a sprint by keeping up thetwo three-week iterations, the forecast is that pressure; keeping them lean; making sure thethe team will only be able to produce 260 points. team has challenged themselves; avoiding theOver this timeframe, the reduction in velocity pitfalls of procrastination, lack of visibility intocapital will result in 40 points of less functional- developers’ challenges and the absence of teamity or fewer defects fixed in the final product. For members; and allowing story creation to crossa team with an average of four story points per sprint boundaries. cognizant 20-20 insights 4
Sprint Length Comparison Challenges 1 week 2 weeks 3 weeks 4 weeks In a four-month project, “ceremonial days” for 32 days 16 days 11 days 8 days sprint planning, review and retrospective In a four-month project, minimum number of ~16 days ~8 days ~8 days ~12 days days spent testing Impact on other team members when a member falls absent in the middle of the sprint – length of A couple of days Several days More than a week A couple of weeks the “endurance test” Unbroken thinking time, allowing for the team 3 days 7 days 12 days 16 days to address challenges as they arise Visibility into team challenges Best Second best Fair Poor Likelihood of falling into the “procrastination trap” None Low Medium High Rare for stories Many stories cross Some stories cross Few stories cross Adaptation to uncertainty in story creation to cross sprint sprint boundary sprint boundary sprint boundary boundary Application feedback Best Better Good Fair Process improvement cycle Fastest Fast Frequent Slow Unsustainable Difficult due to Escalations Adaptation to F500 enterprises that still operate Best; few escala- without isolation many escalations required but less in traditional models tions required strategy required frequentlyFigure 1The challenge with shorter duration sprints is standard. Note that there is a series of reasonsbreaking the stories into small tasks and reas- why two weeks has become the default.sembling them into a unit of work that will bemeaningful to the product owner. Consider this: You should ask the question, “if we change to aIn a one-week sprint, the team will have three different length sprint, what problem does thatproductive days to design, build, test and polish solve?” Are there underlying problems, like per-a component. Given the uncertainty in software sonality or behavioral issues that are manifest-development, this doesn’t allow for much time for ing themselves in other ways that would be bestrecovery when the unexpected occurs, causing addressed in another way than changing thevelocity to appear uneven across sprints. Also if sprint duration? Generally speaking, it is better tothe increment produces too small a delta for the set the cadence and have the team adjust to itproduct owner to notice the update or change rather than the other way around.from the last sprint review, then your sprints may No matter what sprint duration your teambe too short. chooses, make sure everyone buys in, then run itSprinting Ahead as lean as you can, and keep in mind the consider- ations raised in this paper.Consider carefully for what purpose you mightdeviate from what has become the two-weekAbout the AuthorBrian Haughton is a Senior Manager in Cognizant’s Advanced Solutions. He is a full-time Agile ScrumCoach and has both CSM and CSP certifications from the Scrum Alliance. His background includes manyyears at a Big-5 consulting firm, with a specific focus on systems integration and content management.Brian previously worked at major online media and logistics companies. He received a Masters in Math-ematics from the University of Mississippi and a bachelor’s degree from Mississippi College. He can bereached at Brian.Haughton@cognizant.com. cognizant 20-20 insights 5