It isn’t too surprising when you see that there are so many different ways to do a retrospective, after all, if there are that many options then surely you are meant to switch it up at the end of every Sprint?

So when should you move onto a new retrospective format? Well naturally if the format you are using isn’t working then consider using a format (more on this moment), but to help here is my decision tree on the matter:

Okay, so maybe there was a simpler way to say this…

If you haven’t used the original technique for more than six times in a row then don’t try something new.

Why six times? It is enough to get a pattern, to feel comfortable with the process so that you can maximise the focus on the intent behind the practice.

If your team has been doing it the same way for longer than that and don’t want to change it, then as a Scrum Master DON’T CHANGE IT. It is their decision not yours to switch it up in this instance.

I’m not going to go into the menagerie of options that you can use for a retrospective, but I would recommend that when you start keep it really simple. Ask two to four questions, no more than that. I still use the original ones:

• What worked well
• What to do differently next time
• What puzzles us
• Lessons learnt.

What I find is a lot of retrospectives fail, not because of the process per se, but because of the little additional “gotchas” that seem to be hard to find as guidelines/rules on the topic. Here are my top tips:

1. Start you retrospective by reviewing your previous retrospective actions. If they aren’t done then focus the retrospective on why the actions themselves aren’t getting done.
2. Don’t commit to more than five actions. You just won’t do more than five.
3. Fix the root cause not the surface issue. To do this, you need to make sure that you actually discover the root cause within your retrospective.
4. Treat the retrospective as a law of thirds – one third define (brainstorm), one third discovery (share) and one third determine (next actions). Teams often make the mistake of not managing time effectively that result in not enough time for actions.

Arya Stark – Stick bad ideas with the pointy end

This is a PO take on Arya’s statement “Stick em’ with the pointy end” referring to her high prowess and knowledge on how to wield her sword ‘needle’.

The Product Owner rule here is to stop starting work if it doesn’t hit the mark from a analytics and validated learnings perspective. We’ve all seen the HIPPO (HIghest Paid Person’s Opinion) effect in action – work that we know shouldn’t go ahead that seems to be fast-tracked. The best Product Owners are ones that are unafraid to terminate work when it is a bad idea, knowing the risks that it may have to their job but holding steadfast regardless.

Ygritte – You  know nothing without validating your hypotheses

Whilst Jon Snow arguably knew nothing according to Ygritte, so too do teams and Product Owners if they blindly go building capabilities without validating problem-market and problem-solution fit assumptions.

Lean Startup gave us a huge shift in the mindset of software development when it began to re-wire our thinking to stop considering everything a requirement and to start to test and learn on our riskiest assumptions.

Great Product Owners not only test and learn on their riskiest assumptions around problem-market and problem-solution fit, but they are critically aware of the different types of cognitive bias and actively struggle against their better-self in order to ensure that the best possible solution goes to market.

Jon Snow – Benefits are coming

It might as well be winter with how much money is spent building work that doesn’t result in the expected benefits. Although most people have heard the of the 2002 Standish Chaos report that cites 64% of features are rarely or never used, this has yet to be considered statistically valid. Again the biggest challenge to how products deliver benefits has come from the Lean Startup community by focusing on a lifecycle that deeply embeds into its core a process of Build-Measure-Learn with critical decision points at the “Learn” stage to pivot (changing problem goals), persevere (continuing on same path, changing solution options) or perish (stop the work altogether).

There is still too much “throw it over the wall and it’s done” mentality in the industry. Leading organisations are deeply embedding this learning cycle into their development approaches and moving away from heavy batch to more flow based lifecycles. Whilst the Scaled Agile Framework (SAFe) is continuing to grow momentum, it is lost on many that implement it, that applied poorly, it creates massive three month batching.

Think about what this means from a test and learn perspective – you release something to market and begin to gather analytics and data. At the same time you start your next Program Increment meeting and create a firm commitment for the next three months of work. Let’s say that after three weeks you get enough data to validate what you just released and with great concern it just isn’t resulting in the outcome expected. You have an assumption about what you need to pivot, but it will require two weeks of work. What do you do?

You can wait to the next Program Increment, which is another two and a half months away, and then deliver a change in another three months (just over a five month pivot – yikes!). You could pull something out of the Program Increment, thus breaking the expectation that was set, further delaying the scoped benefits. If you were smart you would have built in some slack into the Program Increment to allow for pivots on released work.

In the field, I have rarely seen either of these decisions occur. Leaders don’t generally allow any slack in a Program Increment and instead tend to drive for the whole increment to be filled up, and then sadly what happens next is they push to have the teams deliver both, breaking their sustainability with a promise of “we won’t let this happen again”, which it inevitably always does.

Whilst you could argue that these leaders haven’t been coached effectively and are misunderstanding the core Agile manifesto value around adaptation for Agile (responding to change over following a plan), it doesn’t deminish the fact that SAFe as it tends to be implemented results in massive batching which in turn reduces the time to benefits and pivoting for benefits optimisation.

Great Product Owners know this and will be empowered to push back against the organisation’s leaders to ensure benefits optimisation. To do this, again the Product Owner will likely need great courage to fend their decision against leaders within the organisation.

Littlefinger – Backlogs aren’t a pit, backlogs are a ladder

For a while I considered using the Petyr Baelish quote “Fight every battle everywhere, always, in your mind. Everyone is your enemy, everyone is your friend. Every possible series of events is happening all at once” twisting it into a quote about stakeholders, customers and predictability of needs, but in the end I used the more known quote, “Chaos isn’t a pit. Chaos is a ladder. Many who try to climb it fail and never get to try again. The fall breaks them. And some, are given a chance to climb. They refuse, they cling to the realm, or the gods, or love. Illusions. Only the ladder is real. The climb is all there is.”

Backlogs are real. The climbing through them to deliver is (almost) all there is. Importantly a backlog shouldn’t be a pit. Product Owners tend to acknowledge all requests from stakeholders and politely put them into the backlog. These get prioritised down at the bottom of the backlog and languish for all of eternity. Great Product Owners will look at not just the important and prioritised work in the backlog as part of backlog refinement, but will also actively remove aged items within it, work that will never get done because it is deemed as too low in priority or value.

Product Owners will also appreciate where they are in the Explore-Expand-Extract stage of their product development and their backlog’s content will be reflective of the stage.

Tyrion – A Lannister always prioritises by value

Need I say more? The answer should be yes. A good Product Owner will prioritise by value, a great product owner will prioritise by value with an understanding of cost, alignment to strategy, market and competitive trends. Value can take many forms – customer value, business value, risk reduction or meeting industry obligations. Balancing value with cost of delay and job size will mean Product Owners can realise benefits sooner. A weighted shortest job first algorithm with relative estimation can be utilised to compare work in the backlog in order to ensure that the highest valuable work is prioritised higher.

Daenerys – I’m not just going to tell the story, I’m going to live the story

Daenerys Targaryen may be the breaker of chains with a goal to break the wheel, but as a Product Owner she epitomises the role of a story teller. Product Owners are passionate about the problem they are trying to solve. They want to get to the heart of it and do this best by engaging directly with customers and deeply knowing the data, insights and pain points about both customers and the business. Ideally the team would be attending the customer testing, but if they don’t then the Product Owner really has to be the voice for the customer, to put help the team to put themselves into the customer’s shoes and deeply understand their needs.

This is where Lean UX and Design Thinking intersect with Agile in order to build the right thing.

More Product Owners in Game of Thrones?

Do you have a good quote conversion from a Game of Thrones character to a Product Owner? If so post in the comments below.

There is probably too much wrong to fix, but I saw a tweet recently that I wanted to tackle. It was originally linking to the Segue Technologies blog:

http://www.seguetech.com/blog/2015/11/03/waterfall-vs-agile-infographic

Naturally some people in the Agile community responded and it is fair to say their response was one of confusion and disbelief. Many thought it was a joke, but I suspected that the creators of the information felt it was a reflection of what they believed to be true and not intended as a joke. I tried to seek clarification to which I got a response:

We develop for a wide range of customers. This is a high level info on 2 different methodologies to show non-developers that there are different approaches.

So it was an honest attempt to educate and provide value. Okay. So let me try to give an honest attempt to re-educate on what I perceive to be some of the errors in this infographic:

Agile Pros:

• Customer approval during all stages:
  Probably just a minor clarification, but approval is a little strong for me. They are involved throughout – what that means is that they agree to the work to be done just in time prior to starting it, then they get to see it when it is nearing completion. In essence, there is a greater focus on building the right product.
• Great for quick launches:
  Okay, but maybe more importantly, Agile is great for getting a product out quickly and getting feedback immediately from customers to know whether you are on the right track. You can continue to build on this product through subsequent iterations.
  I want to take a moment and comment on the usage of the term “customer” through the infographic – I am concerned that it is referring to a customer in the business as opposed to a real customer who uses the product. Also there is a lack of distinction on project and product throughout.
• Prioritised by business value:
  Business value is important and should definitely be used as one means of prioritisation, but there are often other considerations used in Agile – Weighted Shortest Job First is a classic example of this. For me, in Agile, prioritisation should include consideration of business value, risk (either technical or implementation), cost, cost of delay and learning value.
• Customer involvement makes project user focused:
  So customer is now distinguished from users (who are the real customers). It may be a little concern of mine, but I do feel the strong focus in Scrum on the Product Owner role detracts us from making greater efforts to get to know the real customers. Yes teams can work hard to ensure they hear the voice of the real customer, but there is nothing like using only customer data to drive your decisions.

Waterfall Pros:

• Early agreement on deliverables:
  The natural risk here on early agreement on deliverables (and I think they mean scope rather than deliverables) is that as you learn things through development, the agreement is moot. Build the right product, don’t just build the product that you agreed to that meets no ones needs.
  If the interpretation truly was deliverables and not scope, there is nothing stopping you from having a great understanding of what needs to be done upfront with Agile. Many teams that I have worked with do an activity prior to going into iterations called “Inception”. The purpose of this activity is to have a common understanding about everything that needs to be done (as best could be understood with so much uncertainty in the complex world of software development).
• No need for customer involvement during development:
  I read this like ‘In software development there is never a need to clarify anything or to get feedback on anything’. Yeah, like that happens, or like that works out to be a great solution. In the early days of Agile when I heard this twelve years ago my response to the business when they said they couldn’t afford to have an ‘onsite customer’ was “okay, then if this project isn’t one of the most important ones for us to focus on as an organisation, that it isn’t critical to invest business experts in for, then it sounds like it isn’t critical enough to invest IT experts in.” The response was always swiftly met with the provision of a good SME.
• Full scope known in advance:
  Never in the world of software development has scope always been fully known in advance. This is just a fallacy and it should be stopped being used by Waterfall appreciators.
  We never build the same thing twice. As a consequence, software development is not a production line, it is a process of discovery.
• Known deliverables reduce chance of “piecemeal” effect:
  There are so many great tools out there for dampening the “piecemeal” effect of Agile – let me name just a few: Inception, Story Mapping, Impact Mapping and Feature Parking Lots.

Agile Cons:

• Disadvantages when team is dedicated full-time on the project:
  Firstly, I am pretty sure there is no rulebook that says teams should be dedicated full-time in Agile. I won’t disagree that it is common practice, nor will I disagree that in almost all instance it is a good thing.
  Secondly, I have done some waterfall projects. People were full time in those too, so it isn’t an Agile thing.
  Thirdly, we have lots of great scientific evidence around the benefits of having team members full-time on work – it reduces context switching, it focuses on getting the work done sooner, thereby delivering value to customers sooner, thereby earning money for the business sooner. If you are interested in learning more about the science take a look at “Product Development Flow” by Don Reinersten. Another good book is “Slack” which talks about the misconception around being 100% utilised.
• Customer may not have time to be involved:
  I guess the project isn’t very important then.
• Customer may redefine scope:
  That sounds like a pro rather than a con. Especially if it means we deliver the right thing rather than waste money on building the wrong thing. The biggest waste as described by Lean is building the wrong thing – in software development this accounts for 64% of features developed.
  Edit: in trying to be accurate on this statistic I discovered it was based on a sample of 4 projects. Those sample numbers are definitely not enough to prove anything. Well at least I learnt something new.
• Quick launches can cause incomplete tasks:
  I don’t know about ‘quick launches’. If this means getting a product to a customer can cause unimplemented scope to occur, then yes I agree it can, and that is a good thing – because we can get value and learn from it. It doesn’t mean that we won’t continue to work on the product, just that when the cost of implementing new features exceeds the benefit then we are probably going to stop. That sounds pretty sensible to me.
  Often in Agile environments we try to automate “launching”. The process of automation inevitably should result in better quality of deployment over time (due to the removal of manual errors) rather than creating more incomplete tasks.

Waterfall Cons:

• Customer only sees final product and could be unhappy:
  In the waterfall projects I have been on with limited customer involvement the ‘could’ has occurred in 100% of instances.
• Customer has trouble visualising project in early stage:
  This happens with either approach. We don’t know what we just don’t know.
• Late changes cause going over project budget:
  Again could happen with either approach. Agile projects should reduce or dampen this effect by delivering the higher value work sooner. But I have to be fair, in my experience most projects I have seen (be them Agile or Waterfall) have had overruns of time (not in production delivery necessarily, but overall effort expenditure). Going over project time often means going over project budget. I feel however our focus on budget/time as indicators to success are sub-optimal, but maybe that is a blog post of the future.
• Late changes extend project timeline:
  As above.

What should factor in your decision – customer preference, project size, customer budget, time to market, customer availability:

• No, you should just always use Agile. I know this sounds dogmatic and like I am a cool-aid person, but when it comes to mitigating delivery risk there really is no alternative to Agile. If you want to deliver with greater success, less risk and with the greatest chance of getting the outcome you want you need to use Agile, it just really is that simple.

1) Do you think that “user story” is just a fancy name for SRS?

2) How do you compare a “user story” to “SRS”?

3) Do you think that “user stories” replace “SRS”?

4) Which of the two do you prefer working with?

So let me open with a clear positioning stance:

User Stories are not a fancy name for an SRS, they are not the same thing, they should replace an SRS when working in an Agile environment and I prefer working with User Stories.

The following comments are focused on how I believe they are different and are naturally based on subjective opinion.

Origination

A SRS is usually created part way through a project, once the Business Requirement Specification (BRS) has been crafted and signed off. An SRS is crafted by a Business Analyst, often with minimal collaboration to other team members and the business throughout its development. As part of its development the BRS is cross referenced to ensure traceability. Once produced the SRS undergoes a review and approval process that does generally have an extensive audience. Often this review and approval process can take several versions until the document is deemed correct.

A User Story can be created at the start of the project or throughout the life of the project. Through a collaborative workshop(s) called “Inception”, features are defined. Often these features are broken down into User Stories using the Story Mapping technique. As everyone who needs to deliver the project is in the room there is no handoff of documents and no extended review and approval process.

The key differences in the origination process is that User Stories are not dependent on the existence of a BRS to be created, that everyone is engaged to identify and define the requirements, and that there is no formalized approval process (because it is not needed if we are one team, all responsible for the outcomes that we agree to).

A simple analogy is that Inception is requirements gathering on steroids.

Content

SRS content is often lengthy, comprehensive but lacking depth to implement against. Normally, an additional deliverable is produced in between the SRS being delivered and software starting coding (normally referred to as a Detailed Design Document, or DDD for short). Field rules, expectations of behaviour under error or abnormal conditions are also specified within (sometimes as an appendix, or separated out into an additional deliverable). There are often multiple SRSs to a single BRS, but rarely would this number exceed a magnitude of 10. How a SRS is tested comes down to separate test deliverables.

A User Story is a promise for a conversation. It is often a single sentence written as a narrative of “As a <persona>, I want <requirement not solution>, so that <value obtained>”. In addition to this single sentence the conditions under which the User Story will be tested are included as Acceptance Criteria. Well-formed User Stories, like system requirements, cross cut components or architectural tiers of the system(s).

Critically there is an expectation that the documentation of the User Story itself is unlikely to be sufficient or comprehensive. The conversation placeholder is the opportunity to discover these elements of the requirements and to clarify needs in person with a business representative. This conversation has representatives from all specialists. This conversation may also extend to a group of developers in order to determine the best architecture or design to deliver the User Story. In this respect a DDD is not normally produced, but photos of whiteboard outcomes are kept in a repository for prosperity. Field rules are often discussed as part of this conversation.

Expectations of behaviour or abnormal conditions are often split out from the story – ie a new User Story is created per condition or behaviour to handle expectations. In this respect a single business need, described within Inception as a Feature, may result in potentially several dozen User Stories. This is especially true when good User Story splitting principles begins to focus on one Acceptance Test per User Story and the team moves towards an estimationless environment of reduced User Story size variability.

Change

As part of the SRS development, as the BRS may undergo several change requests. As part of the DDD development, test deliverable development, actual development & testing the SRS may also undergo several change requests. Over the life of a Project this could result in hundreds of change requests to approved deliverables – this is to ensure that what is delivered is of value to the end user, otherwise the system is unlikely to meet their needs. Each one of these change requests takes the team away from delivering to estimate the impact of the change.

As User Stories never undergo an approval process they can be changed at anytime prior to a developer picking it up to deliver. The cost of change at this point in time is negligible with conversations often being the only highlight. Once development has begun there an team internal change policy often guides what happens next. As a rule of thumb, if the change would take the team less than 30 minutes to do then it should be absorbed, otherwise the change should be raised as a new User Story. That User Story then gets prioritised by the Product Owner and may or may not be done based upon that priority. As a rule of thumb, unless the original User Story was completely off base, then it would still be delivered as it stands, otherwise it would be pulled from development.

Realising value

A SRS does not have it’s value ever realised or assessed. The BRS is tied to benefits and it consequently gets assessed for benefits realisation. Only through traceability of requirements is there confidence that the SRS realises value. From a delivery standpoint, only once all the SRS(s) and BRS has been delivered does the software often go into production. The outcome, is often a delivery near the realm of a year or more. The benefits realisation activity is consequently months, if not years after the production delivery.

Both the Features and the User Stories realise value within their originating narrative of “so that…”. As developers deliver User Stories they can go into production once they have been tested against their acceptance criteria. For iteration based team this often means fortnightly deployments to production and consequently a fortnightly realisation of value. Sometimes teams may not release to production at the end of these iterations because a minimal viable product is still not achieved. Some teams, especially those that have focussed on technical excellence through continuous integration and continous delivery, can realise value several times a day through regular deployments to production.

When Agile teams take on Lean Startup practices a User Story does not get deemed completed or done until analytics have been gathered in production to prove or disprove the value realisation.

A good analogy of Lean Startup as it applies to User Stories is “continuous micro benefits realisation”. In this respect, Agile teams have a higher confidence that they are reducing the #1 waste in software development – building the wrong thing, because they are constantly checking with real customers if they are on the right path (not the proxy customer who may be the Product Owner or Business Stakeholder). The other key difference when Lean Startup applies to User Stories is that the narrative alters to no longer be a requirement and instead is a hypothesis that critically should be proven.

Estimation

When a BRS is completed the service delivery team does a detailed estimate to deliver not only the SRS, but all artefacts and actual software delivery outcomes. The change request process is often the only means to recover further money. Critically, this estimate is done when the largest amount of unknowns are still unknown. Re-estimation after the SRS is completed is not normally done, especially in fixed price bidding environments. Estimates are commonly done by Project Managers and Architects and have next to no input from the people who actually do the work. There is no relationship to SRS and actual delivery rates (with the exception of the rare teams that still do Function Point Counting).

In Agile teams estimation is done throughout. Both Features and User Stories are often estimated, but critically not in hours or days. Instead Agile teams used comparative based estimation techniques where one User Story’s complexity is compared to other already existing estimated User Stories to best gauge its approximate size. As teams begin to deliver User Stories they track throughput rates, either by cycle time or amount of work done within an Iteration. This information is then used to forward project confidence of delivery. All team members are actively engaged and encourage to estimate the User Stories as a single unit.

Conclusion

It is hard for me to write all the above content and not continue to think “Why do we still do waterfall?” especially in the commercially fast paced world that we live in these days. An SRS is not the same thing as a User Story. The outcomes that each achieves are quite different because of how they are utilised, not because of the description of the need that is within them.

If you must do some pre-project prep, so be it. Please don’t name it “Sprint 0″ that makes it seem valuable. It isn’t.

Delving further into the tweet I learned that “many use Sprint 0 to enable bad habits” (don’t disagree), that it maybe should be called “project chartering” instead and that a more common definition of a Sprint is “a time-box for delivering a Product Increment”.

So what is the common goal of a Sprint 0?

The Sprint goal (by my definition) behind a Sprint 0 is “being ready and able to deliver business value that is usable and potentially releasable”. If you are ready to deliver business value then Sprint 0 is officially done.

Do all projects need a Sprint 0?

I say projects here quite deliberately as a team that is already functioning and already delivering are highly unlikely to need a Sprint 0 unless a specific set of features coming up dramatically impacts the ability to deliver business value inside of the Sprint.

If your organisation is onboard the DevOps train and XP practices are well established then you may not need a Sprint 0. If environments can be created and built upon in a day, if standards and frameworks are well understood then you may be ready to start delivery business value straight away.

This ultimately is highly dependent on your organisational capabilities.

Where does story elaboration fit in with respect to Sprint 0?

Teams quite commonly use the time whilst in Sprint 0 to also elaborate further the User Stories for the first value delivering Sprint.

You don’t have to have elaboration one Sprint ahead, but it can potentially help reduce carry overs, reduce time spent in Sprint Planning and ensure that task cards (if you use them) are well defined.

In an ideal world User Stories would be small enough and complexity low enough that carry overs are minimal and elaboration can occur within the Sprint.

What cadence activities should occur in Sprint 0?

Sprint 0 should be, from a process perspective, exactly the same as any other Sprint. It should be planned upfront through Sprint Planning, work should be broken down into items that are achievable within (ideally) 1-3 days, it should be slapped up onto a story wall/task board and tracked, Daily Scrums should talk about what everyone is doing and enable collaboration and sharing. At the end of the Sprint you should demonstrate what you have achieved within the Sprint Review, “Hey take a look at this box, this is the box that builds our code and automatically deploys it. Here look at it compiling and this is the result (good and bad) that it generates”. The Product Owner may not care but I can assure you the rest of the team will. Additionally it is a great opportunity to start reflecting about how you have worked together as a team and see what can be improved.

Just as per other Sprints the work that is done in Sprint 0 should be prioritised. If it doesn’t enable you to deliver software in a Sprint then it probably isn’t high in priority.

So in essence, all the standard, normal Sprint activities that occur when business value is delivered should also occur in Sprint 0.

How long should Sprint 0 be?

Just like value delivering Sprints, Sprint 0 should be timeboxed. The ideal value to set this timebox to is the same duration of your value delivering Sprints. When you do this it is a great test to see if the Sprint length works for you and also a great test of your planning process – were you able to achieve what you had planned?

The trouble with this is that in almost all cases the team’s velocity has not been established and consequently the likelihood of not delivering to expectations is high. If you are going to fail on estimation versus delivery (which I can safely say you will) then this is the time that it first shows itself. This then sets the team on a slippery slope as already from the first Sprint you are behind expectations. How will management react to this message? How long will it take for pressure to be pushed onto the team?

For low DevOp maturity organisations it is entirely possible that the time it takes to get ready to deliver value is longer than a Sprint. This is where the concept of “Sprint 0″ as a term fails and you see people then try to fix it through using “Sprint -1″, etc. This slippery slope further erodes management trust.

I fail to see a magic bullet for this particular problem other than having good planning upfront and always asking “do we really need to do this to begin delivering value?”

What if the team is able to deliver value earlier than then when the Sprint will end?

Then start delivering value. If it is a week earlier, you might want to re-organise the Sprint start and end dates. If it is a few days then it is probably a good idea just to let the Sprint run its course and ignore the velocity for the Sprint.

What if the team is unable to deliver value by the end of the Sprint?

If there are just a few outstanding items then start the first business value delivering Sprint, being cogniscent that it will impact your velocity a little. If there are considerable outstanding items then this should be discussed in detail at your retrospective. Why did this happen? Was it because impediments were not removed? Should an additional Sprint be added? If another Sprint is added then does it affect the ROI of the project? Should we just call it quits now?

How long after Sprint 0 is finished should you wait to start doing Sprints?

Don’t wait. Get started delivering that value!

Where does team onboarding fit in?

The day you start Sprint 0 is the day all the team should be onboard. Arguably they should have been onboarded earlier when you initially created a Product Backlog through Inception workshops.

What are the common pitfalls of Sprint 0?

The obvious one is that teams never get started delivering business value. They stay in this mode of never being ready and there is no drive or motivation to move out of it. Sometimes this is for very valid reasons, for example, developers don’t have PCs or an environment to work in; but often it can be just rats and mice outstanding.

This is why it is important to have Sprint 0 considered a Sprint because the Scrum Master should be driving the team to the goal of delivering value in a predictable manner.

So what is the Scrum Guide definition of a Sprint?

The Scrum Guide defines a Sprint as:

The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable,
and potentially releasable product Increment is created. Sprints have consistent durations
throughout a development effort. A new Sprint starts immediately after the conclusion of the
previous Sprint.

So by the above definition it is wrong to call everything that I have said above a “Sprint” because it doesn’t result in a potentially releasable product.

But the Scrum Guide goes on to say:

Sprints contain and consist of the Sprint Planning Meeting, Daily Scrums, the development work,
the Sprint Review, and the Sprint Retrospective.

which aligns with the above activities that should occur as you prepare to deliver business value. Not surprisingly the Scrum Guide does not say anything about Sprint 0, mostly because anything that is before Sprints fails to exist as a process step or activity (the initial backlog creation being a great example).

What’s in a term?

If you should have for Sprint 0 a Sprint Planning Meeting, Daily Scrums, dev work, Sprint Review and Sprint Retrospective why would you not have a term for this special case that does reflect the word “Sprint” in it, after all, three of the cadence activities in them have the word “Sprint” in them.

If you want to use a different term, lets say “Project Chartering” then you are still having a Sprint Planning, Sprint Review and Sprint Retrospective… but not in a “Sprint”. This seems a little odd and misleading to me.

I feel that the messaging to people starting Agile should be clear and simple and removing the word “Sprint” does not align logically with that. I feel that the word “Sprint” is incredibly applicable and that the definition of “Sprint” in the Scrum Guide needs some common sense flexing of interpretation. I don’t expect the Scrum Guide to change, but do expect some guidance somewhere about how this pre-Sprint is a special exclusion from the delivering of value component in the guideline.

You could always just change the name of all the cadence activities but I think that goes back to not having a simple message.

So what would I call it? I agree that the ’0′ in ‘Sprint 0′ is misleading. I would call it something like ‘Delivery Enabling Sprint’. Make the implicit explicit.