DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. Scrum Myth: It's OK to Have Special Sprints

Scrum Myth: It's OK to Have Special Sprints

Sure, Sprints like Design Sprints and Hardening Sprints may be ''special'' ...but that isn't necessarily a good quality.

Alex Ballarin user avatar by
Alex Ballarin
·
Feb. 05, 17 · Opinion
Like (0)
Save
Tweet
Share
4.19K Views

Join the DZone community and get the full member experience.

Join For Free

One common consequence of teams that do not deeply understand Scrum and the nature of its events is that they believe it is possible to run Sprints that do not produce a Done and releasable Increment of the product. This belief typically leads to dangerous consequences, so it’s important to caution about them and to review the basics of what is a Sprint.

A Sprint Goal Is Always to Produce a Done Increment

The Scrum Guide starts defining a Sprint with this sentence:

“The heart of Scrum is a Sprint, a time-box of one month or less during which a ‘Done’, usable, and potentially releasable product Increment is created.”

Why is that? A Sprint is based on the empirical process control theory to optimize the predictability and the risk control of the development activities. The three pillars of this theory are transparency, inspection, and adaptation.

Producing a Done increment it’s the best way to create transparency about the ability of the team, within its context, to bring value to the customer by delivering that usable and valuable increment of the product. Inspecting the outcome of the Sprint unveils possible improvements to both the product and how the team worked. That inspection allows adapting the course of the development regarding the product, the team, and its environment.

Therefore, Sprints not designed to produce a Done increment undermine the empiricism of the development and do not meet the basics of Scrum.

Let’s review some popular “undone” Sprint types.

Sprint 0

A Sprint 0 is the name often given to a short effort to create a vision and a rough product backlog which allows creating an estimation of a product release. There is nothing bad in doing that as long as everyone concerned has clear that the plan is subject to change as more is known as a result of the inspection of the sprints outcome. To sum up, that activity does not meet the definition of a Sprint in Scrum, so it is better not to call it so.

Design Sprint

A Design Sprint is the name given to a Sprint dedicated to creating a functional design or a technical architecture to guide the rest of the release. This is a worse case than the previous because on top of not meeting the definition of a Sprint, it narrows or even impedes the needed inspection an adaptation of the following Sprints. Again, doing a lightweight functional and architectural design as a part of the product vision can be helpful to avoid risks and put all stakeholders on the same page, but do not create a detailed and final design.

Hardening Sprint

A Hardening Sprint is to me the most worrying interpretation of what a Sprint could be. This concept was widespread by a popular scaling framework that partially changed their mind about this in its last version. A Hardening Sprint goal is achieving a releasable and integrated increment that eventually could not be achieved before. That means that it is accepted that Sprints can create undone increments, so the ability of teams to create transparency, inspect, and adapt are seriously jeopardized, and therefore, no real Sprints are being performed.

Closing

In this post, we saw why a Sprint must always produce a Done increment, some popular myths about “special Sprints,” and some consequences of ignoring the true nature of a Sprint.

Sprint (software development) scrum IT

Published at DZone with permission of , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • What Should You Know About Graph Database’s Scalability?
  • Kotlin Is More Fun Than Java And This Is a Big Deal
  • Load Balancing Pattern
  • Java Development Trends 2023

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: