11

Sprint: an arbitrary length of time over which you implement and release software features.

From what I've read here and other places, it seems that the benefits of a Scrum sprint are that at the end of a sprint you release the software, get feedback from the customer, etc.

But on a web-based product, where I am the owner (the end user is the customer) and we communicate small improvements right when we make them rather than waiting for some Sprint to end, and the customer gets the new features right when they are implemented, what are the benefits of "ending" a sprint?
(other than a post mortem, which we don't do)

Improve this question
4
  • 1
    Perhaps this is an element of process improvement you should be discussing with your team at your retrospective?
    – Nathan
    Commented Feb 14, 2017 at 8:13
  • 2
    @NathanCooper it doesn't appear OP's team is having retrospectives. (I would highly recommend they start though)
    – RubberDuck
    Commented Feb 14, 2017 at 14:35
  • 2
    If you are not having Retrospective's then that's a slightly more serious issue than asking questions about the value of a Sprint IMO but the question has been answered it seems.
    – Venture2099
    Commented Feb 14, 2017 at 19:22
  • You're trying to pick up a tool to fix a problem you don't know - maybe using Sprint would become a very good and powerful hammer... for your screws.
    – Tiago Cardoso
    Commented Mar 13, 2017 at 22:47

3 Answers 3

Reset to default
14

TL;DR

  • A Sprint enshrines your empirical process by providing a maximum delivery cadence
  • It increases communication and alignment
  • It adds some predictability to the unpredictable nature of software by evening the batch sizes.

A Sprint is a container for planning!

While the Scrum Guide says that you must deliver working software at least every 30 days there is nothing to stop you doing it more frequently. Indeed continuous delivery and Scrum go together quite well in my experience.

A Sprint enshrines inspect and adapt by containing your other feedback loops:

  1. Sprint Planning - Inspect the Backlog and Adapt the plan for the next Sprint
  2. Daily Scrum - Inspect progress and adapt the plan for the next 24hours.
  3. Sprint Review - Inspect the Increment and adapt the Backlog
  4. Sprint Retrospective - Inspect the Sprint and adapt the process.

Without a Sprint when would you bring all this together? It makes them mandatory efforts as they should be. If you are an awesome disciplined team then by all means do something that looks a little more like Kanban, but if you don't have the discipline to follow the rules of Scrum, how would you expect Kanban to work?

Communication & Alignment

An additional benefit of Sprinting is that it gives a cadence that your management, and other dependent teams, can follow easily. If you are coordinating work, then having a common frame of reference, Sprint 231, will aid in communication.

Creates Predictability

Since software is a creative endeavour and the standard deviation of a batch is so wide an unpredictable the addition of a fixed time container artificially created some predictability in your batches.

I would say that there is a good deal of value in a Sprint.

Improve this answer
7
  • 2
    In short, it establishes a cadence & rhythm to your work. ++
    – RubberDuck
    Commented Feb 14, 2017 at 17:11
  • Scrum Guide does not say that at all. It says "The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done.” It must be in useable condition regardless of whether the Product Owner decides to actually release it." Nowhere does it say software MUST be released every 30 days. In some deliveries (EG automotive or aerospace) this would be impossible.
    – Venture2099
    Commented Feb 14, 2017 at 19:40
  • 1
    The Scrum Guide does indeed say "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." <-- One Month or Less...
    – MrHinsh - Martin Hinshelwood
    Commented Feb 14, 2017 at 19:56
  • 1
    And nowhere in my answer did I say that it needs 'released', hence my confusion. "Scrum Guide says that you must deliver working software at least every 30 days there is nothing to stop you doing it more frequently".
    – MrHinsh - Martin Hinshelwood
    Commented Feb 14, 2017 at 21:29
  • 1
    +1 to @MrHinsh and Venture2099 regarding 'releasable.' The most important distinction in the Scrum guide regarding the Product Increment is that in less than 30 days, it must be releasable. This enables release to become a business decision rather than a technical decision i.e. can we release this>
    – jason.t.knight
    Commented Mar 4, 2017 at 0:02
3

You may find under your situation that a Scrum Sprint model does not fit well. It is just one way of doing things. Perhaps you are looking more of a Kanban approach

As for the usefulness of a sprint itself, if a team of people are able to work together to complete a piece of functionality that meets the sprint goal then it can be quite rewarding for them to release on sprint boundaries.

Scrum does not mandate a release at every sprint, that is upto the Product Owner and team. But it is extremely important that the product is in a "potentially shippable" state, which means good, working quality softare is available to be released on a regular basis

Improve this answer
1
  • No it does not @MrHinsch. Stop spouting this rubbish. Here is the official statement. The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done.” It must be in useable condition regardless of whether the Product Owner decides to actually release it. Source: Scrum Guide V3
    – Venture2099
    Commented Feb 14, 2017 at 19:39
2

The biggest reason for sticking to a consistent sprint length would be in order to have predictability. Since velocity is the average of the work you have accomplished in a given time period, it would be unusable if sprint lengths were inconsistent. A useful velocity can give more confidence to a team who is committing to delivering a feature in a certain time period, and it also helps the team estimate and forecast a longer-term milestone for your project.

Reasons for sticking with consistent sprint lengths depend highly on what sort of environment you are in. Scrum does not prescribe that releases happen at the end of each sprint, and continuous delivery is certainly one of the most common reasons to forego this practice. Kanban may be something worth checking out if you are in an environment with a continuous flow of tasks.

Improve this answer
10
  • There is no such thing as an accurate velocity, it is a fallacy, and its pursuit is a waste of time. The Scrum Guide stipulates that you must get working software in front of your customers at least every 30 days.
    – MrHinsh - Martin Hinshelwood
    Commented Feb 14, 2017 at 17:02
  • 2
    @MrHinsh Precision and accuracy are very different. It's impossible to get a precise estimate based on velocity, but it is certainly possible to get an accurate estimate based on velocity. One can easily use velocity to estimate that a milestone will be reached in 9-12 months (accurate,) versus a specific date (precise.)
    – Casey Sprague
    Commented Feb 14, 2017 at 17:13
  • 1
    I disagree; as the standard deviation of most teams velocity, sprint on sprint, is soo high that the average (mean) is too far removed from reality to be realistically used.
    – MrHinsh - Martin Hinshelwood
    Commented Feb 14, 2017 at 17:14
  • @MrHinsh perhaps "useful velocity" would be a better term to avoid this confusion. Updated.
    – Casey Sprague
    Commented Feb 14, 2017 at 17:40
  • 1
    @MrHinsh being velocity is a lagging measure, it is always accurate. Whether or not it's a useful indicator of future performance is another matter entirely... IME it's not.
    – RubberDuck
    Commented Feb 15, 2017 at 17:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.