Scrum Myths: It is ok to have a Sprint 0, Design Sprint, Hardening Sprint...

Oh the beauty of Idealism......
Too bad the world doesn't work that way. Nor is it practical to think like this.

You yourself already say that the work that is being done in "sprint 0" needs doing. Why then should we tell people "You're bad for calling it a sprint!"? If that's how people can understand what needs to be done then that's what we'll call it.

Same goes for "hardening sprint". It's wrong to define up front that you're going to do one as that makes people take shortcuts on the Definition of Done. But if you're working on legacy code there's bound to be a huge stack of technical debt. Why not designate one sprint to actually get rid of (some of) that? It makes for good focus and a good sprint goal.
The statement about SAFe dropping this in the latest release is also false. It was dropped in SAFe 3, some 4 years ago. In our line of work that's ages ago. It's been a long, long time that anyone thought a planned hardening sprint was a good idea.

So to reiterate: Yes, in the theoretical world of fairies and unicorns your statements are quite right. Too bad there's no Scrum in that world at all. Scrum exists only in the real world where it's more important that people understand things than whether they use the right semantics. Where sometimes systems need some time of full focus on removing technical debt instead of saying "hardening sprints are wrong".

Wow Koen van der Pasch, just wow!

Thanks Alex for bringing this up. I agree with you wholeheartedly. I've found in the real world your approach works really quite well. It allows the team to focus on items of customer value earlier than otherwise may have happened.

It doesn't preclude those things that need to be done up front, that could be included in what some call a Sprint 0 or after in a Hardening Sprint.

I find that labelling the first Sprint as Sprint "0" and designating architectural and design PBIs only sets an unrealistic expectation to the Product Owner that the team will have completed all these precursor PBIs and from then on there will be only PBIs of business value being built, which isn't the case in the real world. Architectural and design tasks are ongoing of course.

So I generally start the first sprint as we're going to finish the last sprint, with a mixture of technical value and business value, with an emphasis on business value PBIs delivering a potentially shippable product, whatever the slice of it may be, and do away with this Sprint 0 and Hardening Sprint approach.

Shane;

If calling Sprint 0 a sprint is causing problems with expectations then your people have missed line 1 of the Agile Manifesto.
Expectations aren't set in semantics, they are set in interactions between individuals. Whether you call the work that needs to be done "preparation" or "Sprint 0" won't change that. The work needs to be done anyway. And if calling it "Sprint 0" allows for a better understanding then call it Sprint 0.

Stating that every sprint needs a mixture of technical value and business value with an emphasis on business value is nice management speak, nice marketing talk, nice Agile Elitism. But the world doesn't work that way. If you're working on legacy software with a heap of technical debt, focusing on business value will only lower the quality of the system, eventually causing a breakdown. Then where does your business value go?
It's what we used to do in Ye Olden Days; budget projects according to their business value. That ultimately resulted in the draconian systems we have today. Sometimes you simply need a "hardening sprint" - a period where you focus on refactoring and bug fixing alone to make sure you can deliver any business value at all in the future.

I know my opinion on this is unpopular. It's also deeply rooted in practice. I think stating "Sprint 0 is wrong" and "hardening sprints are wrong" is Agile Elitism and exactly the reason why we're currently in the trough of disillusion as far as Agile goes. Agile has been promising "We don't need any bug fixing anymore!" for years and unable to deliver on it since 90% of our work is not greenfield work.

I think back to Henrik Kniberg's "Product Ownership in a Nutshell" and be honest to everyone about Agile. Stating "Hardening sprints are bad" is not being honest.

" I think stating "Sprint 0 is wrong" and "hardening sprints are wrong" is Agile Elitism" - the sprint is not a concept related to agility but to Scrum as a framework. Scrum defines its vocabulary as a way to shape the mentality in the approach to value delivery. If we agree on what a Sprint is then there's no point in calling a Sprint something that falls short of the definition. It's not elitism (Scrum elitism if you will) to keep to the context in which terminology is defined. This doesn't mean you should be limited to terminology, by all means do whatever it makes sense for your activity, but don't redefine the term within your own context. Otherwise we lose the common language.

I don't agree that Hardening sprints are necessary. I've never met a situation where a Hardening sprint is the absolutely only way to go about tackling technical debt. There are plenty of ways to pack backlog items attacking technical debt around valuable improvements. Your goal is always to deliver useful software, if none of your backlog items aimed at that allow for work to be done towards tackling technical debt then there's no point to do it ... you don't work towards pure technical excellence but towards useful software and that's something to attack only when it sits between you and the achievement of your backlog as a whole.

Ad Sprint 0:
The question is, Andrew, what the goal is. If the goal is a common language, or adherence to terms defined in a process then you are right. If the goal is to deliver valuable software then there is no reason not to call it a sprint. If the interaction between the people is served by calling it a sprint then I refer, again, to Rule #1 of the Agile Manifesto.
Scrum is a tool or a process. Nothing more, nothing less. Saying "Sprint 0 is wrong" puts that tool or process above the interaction of individuals.

As for hardening sprints; I agree that delivering valuable software is still the highest goal. But one has to look at what "value" is in this case. Stacking technical debt will destroy velocity and is thus Bad(tm). The highest efficiency is attained by focus and thus focus is Good(tm). This means that in the long run, over the whole, a hardening sprint, where there is full focus on quality improvement, can be a good thing.
The only reason why we want to deliver valuable software each sprint is to improve the feedback cycle. The question you have to ask, then, is what is more valuable; The higher productivity of the focus of a hardening sprint, of the feedback you get from delivering something valuable.
Simply stating "Hardening sprints are bad" shows a lack of understanding of the deeper layers. It means you only focus on "delivering valuable software", not at why we want to deliver valuable software.......

Hardering Sprint is just something to avoid by essence. And why not just commit to deliver a scaled small useable software.artificats with a lot of architectural/technical/commercial/Business study in the Sprint 1?
I think we should keep that Scrum Good Ideas which aim to produce better S/W in a better team working and good mental environment.

quote:
"And why not just commit to deliver a scaled small useable software.artificats with a lot of architectural/technical/commercial/Business study in the Sprint 1? "

Because we don't live in a perfect world where everyone is doing greenfield work. Some of us are working on legacy software, some of which is 25 years old. That just doesn't have the quality we can now get with greenfield work.

These are all common issues that result in the loss of quality product development and delivery. There are some minimal pre-Sprinting activities that need to be accomplished, but they need to be completed on their own because they are outside the definition of a Sprint. When the Product Backlog items are well defined, properly limited in scope, well understood, and of value then the required design can be achieved during the Sprint Planning event. If an organization is not delivering a high quality (including well tested) product increment at the end of each Sprint then they are failing to embrace both the Scrum framework and the philosophy in the manifesto. Accepting these, and other classical mindsets and practices, as necessary are indicators that the agile philosophy is not understood or has not been truly embraced.

No, indeed the goal is not the common language. The common language is the means through which we collaborate. I'm not sure how you state that the goal is to deliver (generally correct) but miss the fact that delivery is done by the team through collaborative work. There's plenty of research and material on the role of common language, promoting communication and how in Scrum in particular the language is what drives change and mentality shift. Take away the common understanding and you're left with trying to somehow change the understanding of the terms by any new team member that arrives, regardless of their experience with this methodology.
In the long run, getting rid of technical debt is beneficial and I'm not saying otherwise. But you have on one hand the option of blending that with actually delivering usable software and doing things for technical reasons alone. I would say that focus is debatable mainly because doing features while getting rid of the technical debt is an invaluable learning tool while working on any kind of legacy system: you get to envision the feature (or whatever change you do) while observing the negative effects of the technical debt attached and at the same time devising technical improvements.
The main problem I have with the focus of a hardening sprint is that in order to have it you need the following:
- a software architect that would devise in advance the changes to do and concoct the architecture in such a way that it can be contained in a sprint, it's clear for developers and do this in a timely fashion while not alienating the QA through the extensive regression testing to follow.
The problem is that this would need to be done in parallel with the team still working on the product and presumably deepening the technical debt just as the solution against it is devised (unless you freeze features for some reason). To me it's a catch 22 that I wouldn't dream of attempting as such, mostly because it's disconnected from all except the immediate stakeholders (sure, we'll reduce the cost of maintenance and development over time versus the cost of not launching features in the meantime ... which may or may not serve the financial plans of the product).
You can also let the team brainstorm solutions in a sort of icebox backlog and then run them through an architect, I guess.
Have you ever tried to quantify the benefits of fighting technical debt while not developing the product? I did and it was a pretty killer job to do (even for the arguably small products I've done this for).

I have a question related to this blog, I am seeing many references to the "Scrum event of backlog refinement" where the team reviews user stories and drafts acceptance criteria. At which point during a Sprint cycle shall we do this?

Other undesired results in organizations feeling the "need" for a "Sprint 0" is that these activities actually distance complimentary skills, necessary conversations and collaboration meant to take place within the Development Team in an actual Sprint. This means there is a limit on emergent architecture and design within the Development Team because people felt it "necessary" to establish the "final" UX Design or technical architecture before Development Teams "are allowed" to start Sprint "1". The very first Sprint starts with a visionary understanding of the product via the early Product Backlog and conversations with the Product Owner. From there, Development Team(s) are professionals, trusted to determine an end-game architecture, and incrementally, emergently, empirically, work toward an end state that is actually needed - prepared to change their heading as reality of what is needed is discovered. The thinking that leads to activities that limit in this way, must be challenged and reserved for Sprints, every Sprint, event the very first Sprint.

John Davis
Professional Scrum Trainer

I don't mind doing a "Sprint 0". As developer I got used to start counting with 0. *g*

As Scrum Master I would say: Get any goal the team can fulfill for itself and result should contain a software that a user can open and click something. And keep your sprint short at the beginning. (1 week)

Why is that! Doing a short sprint minimizes risk and waste. Having a small software which maybe will get thrown away later because the architecture needed can not be done with that tool is at least a starting point for discussion and feedback with the end-user.

After the first week you have a better formed team, experienced your developers, checked if that one tool will be yours and had time to bring devs and users together.

You will have ideas what to do in the second week.

Honestly said I do not quite follow the reasoning against the sprint 0; of course it's clear that is not really a sprint! it's the preparation for the first sprint and nothing more (setting up development/test environments, create definition of done with the team, gather and refine first backlog items, ...). We could indeed (originally) have used a different name for this preparation, but in pratice it's called sprint 0 and it's pretty clear for most people what the result should be of that timebox - I like transparent and clear communication and using the known name helps for that :-)
Regarding a design sprint: agreed - really not Agile. Almost same category as the team that wanted to do a short testing/implementation sprint after each normal sprint.
Regarding a hardening sprint: I would definitely prefer not to use/need it, but I can imagine circumstances in which it could be a solution.

These articles, although well intentioned, neatly side step the reality of enterprise organisations.

Scrum continually refers to these mythical, startup like environments where complete code coverage and full integration testing can be achieved in Sprint. There are no design stories and code reviewers are immediately available. There are no third party constraints or legislative penalties or timelines or planning artifacts. All team members are beautifully cross-functional.

This dogmatic approach to the Scrum Guide merely leads to frustration in junior SM's and Product Owners.

The truth is, in enterprise organisations that have decided not to prioritise the adoption of Dev Ops it is highly unlikely that integration testing and automation will be completed within a Sprint. A hardening Sprint is not the answer, it may be that we need some integration testing stories (another practice drawing scorn from the community).

When coaching new ScrumMasters I simply tell them three things

- You cannot evangelize Agile values if you are fired. Softly softly, document all advice. Get along before you go alone.
- The only metric that matters is working product. No one is giving gold medals for doing Scrum 'correctly'. If you need an integration testing story but the enterprise organisation only run integration testing every 6 weeks then write the damn story.

Lastly...

- Scrum is not the thing. It's the thing that gets you to the thing.

These kinds of articles offer 0 advice to new Scrum Masters and experienced Scrum Masters know enough to simply skim over them as zealotry. It's why Mike Cohn says you can have as many Definitions of Done as you need. In the gaming industry they may 4 or more Definitions of Done.

Come on Koen, if the Scrum community are not rabidly attacking the "wrong way" to do Scrum how can they sell more courses?

I was offered a Backlog Refinement Meeting training course by an official Scrum organisation a few weeks ago. All for the bargain price of over a $1000! *laughing crying*

I am being flippant but also making a serious point.

...and in that world you described there are no Technical Design Authorities, no legislative constraints and complete autonomy.

Which specific IT company have you worked in with that total freedom?

Backlog refinement can occur at any time during the Sprint but the community have generally settled on scheduling it mid-way through the Sprint at the half way point.

The idea is to review the potential user stories prior to Sprint Planning. It ensures that Sprint Planning is as seamless as possible.

If the team have a backlog that is refined enough that you don't need to focus on Sprint Planning items then you can really get some advance awareness of your future Sprints. Ideally though...you don't want to get too far ahead since the Product Owner may reprioritise.

Hi Alex, very good blog post here. Just minor correction. Scrum is based on Empirical Process Control not Sprint

There's so much negativity and sarcasm here that the first line of the Agile Manifesto seems to have been abandoned.

I think that a large part of the problem is the desire of organisations or projects to say that they are doing Agile/Scrum when in fact they aren't suited, culturally, to the framework. I've seen examples of this, and would like to say to those organisations and projects "Don't worry, Agile isn't mandatory. If it doesn't fit then find another way to work. But please, don't try to bend Agile to suit your needs and then try to sell your way of working as Scrum".

I think it's absolutely fine to call 'Sprint 0' for a project, which is already not in-flight, but could be in conceptualisation or discovery or initiation phase of an agile delivery cycle. Sprint 0 is a precursor sprint, where a prototype could be built, while the discovery is actually happening in parallel, to eventually fortify the foundation laid for building the product from Sprint 1. When we allow day-zero, Zero-hour etc., why not Sprint 0?

What about user research, prototypes, usability test and other cheap validations you can do through design? Do you do that during the sprint? What does the development team do while that happens? Join and don't code at all until things are refined and validated? Giving a beautiful and visionary business problem to the development team to jump and create an "end-game architecture" or even product solution without any UX design doesn't sound like a smart idea to me.

As you know, the point is to deliver working functionality. It does not have to be exhaustive delivery. We have other sprints. We are looking to meet a few acceptance criteria (maybe a few days), for a larger body of work (maybe a month); and make sure that they at least meet our definition of done. We can put off end to end testing for the month. But we should find a way to shift our story telling and our a/c to be specified by a use case. This begins to allow for early closing and leaner solutions (where we just focus on meeting the use case).

Let's just clarify something. A design sprint in the context of Scrum is NOT the same as in the context of Innovation as Google Ventures invented it circa 2010. This next article explains the difference. https://uxdesign.cc/design-...

I came across this post a while ago and now I am reviewng it again because somehting jumepd at me and I need to ask to clarify: when you refer to Design sprints are you refereing to those of the google Venture's recipe or are you refering to a malpractice people do when trying to include design work into the scrum cadence? I want to make sure if the later was actually a phenomenom that still occurs to this day.