There is nothing new about project preparation. It doesn’t matter how it is conducted, as long as the organization and the project team take some actions to ensure a majority of key obstacles are removed or mitigated. Have you seen projects halted — or worse, canceled — when progress was impaired to the point of utter chaos?
On Agile¹ or Scrum² projects, project preparation activities are often known as “iteration zero,” “sprint zero,” or “inception sprint.” An investment in project preparation can vary depending on the complexity of the product, schedule constraints, the availability of skilled personnel and critical environments, and the amount of customer involvement. From our experiences, sprint zero activities for large teams are critical to ensure things go well from the start. A majority of our Agile work activities during the last 20-plus years has been with large, distributed teams that support government contracts in military weapon systems, avionics, mission planning, and satellite development. Small teams that are serious about paving the way to successful project execution perform some preparation, but not on the same scale as larger teams and projects. However, preparing for a project should not turn into a project itself, and while there is no set time for such preparation, budget and schedule constraints may be a major timing factor.
To be consistent herein with terms used in Scrum, we shall use the term "sprint zero" in this article. Also, the point of this article is to emphasize how vital sprint zero activities are to the success of any campaign, endeavor, mission, operation, program or project.
What is Sprint Zero?
The definition of sprint zero is vague. Its roots likely originated from costly lessons learned when things went awry during initial project execution. Typically used before an Agile or Scrum project commences, sprint zero has never, to our knowledge, been defined very well. The authors of this article believe the critical activities conducted by preparation or sprint zero are paramount to the success of any project. Such critical activities include the following:
- Identifying an Agile Champion.
- Writing some high-level user stories.
- Preparing an initial release plan.
- Training everyone on the benefits and use of Agile.
- Obtaining stakeholder buy-in prior to implementing any Agile method.
- Identifying a product owner (one per project).
- Identifying a Scrum Master (or Scrum Masters if multipleteams will be employed).
- Identifying personnel that meet all requisite skill sets.
- Obtaining approvals from activity executives (who provide funding) and senior management (who provide personnel and other resources).
- Establishing all necessary infrastructures (e.g. test benches, racks, harnesses, initial architectures, Wi-Fi, and so on).
- Establishing all critical environments (e.g. test labs for operations, the software development area, team areas to support daily stand-ups, and so on).
- Creating just enough architecture to support initial sprints.
- Determining the most likely and the most significant risks.
- And more.
Many companies that teach Scrum do not mention sprint zero due to its unacceptable and controversial nature and its Scrum-like term. It could also be that sprint zero is not an Agile or Scrum activity, thus the resistance to the "sprint zero" term. The following are a few vague attempts to define sprint zero by both those who execute it and those who abhor it:
- Sprint zero is usually claimed as necessary because there are things that need to be done before a Scrum project can start.
- Sprint zero has three goals:
- Populate the product backlog with quality items.
- Provide a minimal environment that enables the writing of quality code.
- Write some code, no matter how small.
- A list of all prioritized features or stories that include estimates.
- A release plan that assigns each feature or story to a sprint.
- A high-level application architecture, i.e., how the features will likely be implemented.
In April 2015, the author, Dick Carlson, posted a question to LinkedIn readers entitled, "Is Sprint Zero for You?" The purpose of the post was to determine how Sprint Zero is regarded by the Agile community and how many people use it. (You can read the post on LinkedIn.) For those who are not LinkedIn members and do not have access to the post, portions of the post are included in the following section.
Is Sprint Zero for You?
The Original LinkedIn Post (April 14, 2015)
Watts Humphrey (1927–2010) once said, "If you don't know where you are, a map won't help." This may sound silly, but have you noticed how often excitement trumps logic when preparing for a new project? It would be interesting to know how many of you support sprint zero before project execution and how many of you avoid sprint zero altogether. Below are a few questions about the conduct of sprint zero, so please share your thoughts and opinions on this very important activity.
- What isthe potential impact that Agile adoption has on a company's operations, and which areas mightbe affected the most?
- Which critical foundational necessities must be completed during sprint zero to avoid major obstacles that might otherwise obstruct progress?
- Who should define all known requirements and create the initial product backlog prior to the start of a project?
- Who is responsible and the most capable person for creating a product vision, a product roadmap, and an initial release strategy?
- Who decides the amount of appropriate architecture that must be created to ensure that the completed functionality can be conducted successfully to ensure the team is building the right thing?
(Latter portions of the LinkedIn post were removed from this article to avoid any perceived marketing pitches by the authors.)
Responses varied widely. Some supported sprint zero, while others had strong negative opinions regarding it. The majority of responses were received within a month. Since the reactions from readers were so mixed, a thorough analysis was needed. Earle Soukup, this article's co-author, took on the task.
The methods and results are explained herein, although an unspecified amount of readers may disagree with some of the conclusions.
Analytical Methods Used
The methods used for the analysis were partially quantitative and partially qualitative, but a portion of the quantitative analysis was subjective. The subjective aspect is derived from the difficulty of assigning a numerical value to someone's statement when its value is based on the opinion of the assessor.
The ground rules for the analysis were simple:
- Each comment was assigned a value from -3 points (very negative) to +3 points (very positive). This includes a value of zero for some comments.
- A comment assigned a value of 0 was deemed to be inapplicable to the analysis. For example, a question or a request for an explanation may relate to the topic but not state an opinion. These comments were assigned a value of zero.
- A comment about any topic other than the subject of the LinkedIn post also received a zero value.
- A response of only a "Like" or a "Dislike" received a value of +1 or -1, respectively.
- A written response received a value of +/-2 or +/-3 depending upon its strength of support or rejection of the topics in the article.
- A longer written comment indicated a more intense opinion about the subject, so it generally received an assignment of +3 or -3.
- A comment containing an intense expression of opinion received a +3 or -3 value regardless of length. For example, "This is rubbish" received an assignment of -3.
- All comments or responses from the author, Dick Carlson, were excluded from the analysis and considered to be part of the original article.
The Results of the Analysis
The analysis revealed both strong (+/-2) and very strong (+/-3) opinions in the Agile- and Scrum-using community. Some respondents were of the opinion that there is an "orthodox" Agile, and any method that deviates from that orthodoxy is not Agile, nor can it be allowed to be classified as Agile. Other respondents were more flexible about using Agile.
Some interesting responses:
- Some respondents ignored the fact that Agile has expanded beyond the realm of developing software.
- Originally the application of Agile was to small, co-located teams, but now Agile is also being used by large, distributed teams.
- Some respondents seemed to reject the idea of evolution applying to Agile.
- Some respondents seemed to ignore one of the key values of the Agile Manifesto, "Individuals and interactions over processes and tools."
- Sometimes the agility associated with using Agile was ignored.
- Other respondents supported the ideas in the LinkedIn post, including the term "sprint zero."
- Yet other respondents supported the ideas in the LinkedIn post, but rejected the use of the term "sprint zero." Some respondents suggested terms would be appropriate to replace the term "sprint zero." Many suggestions had merit, but a few might introduce an ambiguity of the purpose for executing a sprintzero activity.
- One respondent expressed the opinion that the concept of sprint zero was apropos since there were zero deliverables at the end of the sprint—untrue, but interesting.
The Major Disagreement
The term "sprint zero" was the largest source of disagreement. The concept was anathema to some respondents. Their general opinion seemed to be that "a sprint must begin with a numeral, and it must produce some operating software at its end, or it is not a sprint." The implication of this statement is that only tested, accepted and executable code counts. No considerations were given to a project using Agile but developing something other than software.
Also rejected or ignored were the concepts that roadmaps, risk assessments, coding standards, and other work products that are valuable to project management. Company executives (who many people consider stakeholders), end-users, and other stakeholders do not count such as deliverable items. (Note: The aforementioned items are considered valuable to those holding the purse strings in a large corporation.)
Other respondents liked the value of the activity but did not like the use of the term "sprint zero." Such comments were assigned values of +2, because a dislike for a particular term seems less important than the value of the effort.
Many respondents agreed with the thesis of the LinkedIn post, either generally or wholly. In fact, on a weighted basis, more were in favor of the thesis in the LinkedIn post than opposed to it.
Some respondents drifted to other topics that were not germane to the subject of the LinkedIn post. These comments were assigned a value of zero (0), though some of these comments were rather interesting.
The Numerical Analysis
The numbers are revealing.
- Responses from the author were excluded, leaving a total of 171 responses from members of several LinkedIn groups, including the Agile & Lean Software Development Group, the Agile and Lean Europe Group, the Certified Scrum Master Group, the Non-Tribal Lean Agile Group, the Lean Agile Software Development Community, and LinkedIn Pulse contributors (who must be LinkedIn members to post such write-ups). The author's responses to comments made from respondents were explanatory in nature. (Note: The respondents included mostly software and system engineers from around the globe.)
- Neutral comments: questions, answers, or off the topic. 20 total responses.
- Comment: commenters provided only one or two comments each; one commenter provided at total of 23. Each comment was evaluated separately.
- Total Points: total, absolute value of the weighted comments was 286 points.
- The positive comments totaled 191 points; the negative comments totaled 95 points.
- The ratio of the positive to negative points is greater than 2:1.
- One discussion group provided 45 comments.
One might believe that for a technical project, the rules of logic would be the only rules that apply. But this analysis reveals that emotions may overrule the rules of logic; thus, emotions can influence technical decisions and opinions. Many people have strong emotions concerning Agile and how to apply it.
Some appear to believe that there is an "orthodox" approach to Agile, and any deviation from that approach prevents an activity from being called "Agile." Other users of Agile are prone to adjust their application to meet the needs of the situation. Their comments supported the approach that the emphasis should be on "meeting the needs of the situation" and not on establishing a process that followed "orthodox" procedures.
The responses from both sides of the issue demonstrated a strong support for Agile and Scrum, so the use of both methods should be viable for the future. Some individuals prefer to follow an "orthodox" approach while others are willing to apply Agile and Scrum in a flexible but comprehensive manner. Flexibility seems to outweigh rigidity by more than 2 to 1.
Emotional attitudes may have a stronger influence on the structure and behavior of a project than many people might believe. If the sprint zero term is offensive to you, then call it whatever you wish, but do not skip this step.
The distribution of responses is depicted in the following chart.
Figure 1. Distribution of Responses ()
As a final thought, essentially all training providers make it very clear that the team's Scrum Master has the authority to cancel a project should impediments and other daunting obstacles become burdensome and overwhelming.
References and Notes
Dick Carlson has an extensive engineering background that includes many years of practical knowledge and hands-on experience in the implementation and deployment of Agile, Lean, and Scrum values and principles in communications-electronics, and software and systems engineering within the aerospace, DoD, IT, and industry domains. He has developed and actively conducted comprehensive training courses for Scrum Teams, Scrum Masters, Product Owners, project/program managers, customers, executives, organizational leaders, and others interested in learning how to implement and deploy Agile, Lean, and Scrum. Mr. Carlson has a Bachelor of Science degree in Business and Management from the University of Maryland, and is a Certified Scrum Professional, Certified Scrum Master, and Certified Scrum Product Owner.
Agile & Lean Education Associates (ALEA)
Mr. Soukup holds a Bachelor’s and Master’s degree in Electrical Engineering, a Juris Doctor in Law, certificates for software development, project management, functional management, systems engineering, and Agile and Lean including being a Certified Scrum Master. He was a development and test engineer, manager, and project manager for both hardware and software. Also he developed and taught courses in mathematics, electronics, ethics, Lean, and Agile. He is an accomplished analyst.
« Previous Next »