Short Scrum and Long Scrum

There are many ways to play Scrum. In some sense, Scrum is infinitely flexible.

Let us pretend for a moment, there are only two types of Scrum, which I will call Short Scrum and Long Scrum.

Short Scrum

In Short Scrum, a Sprint might be completed in one day.  So, we do not have a long Product Backlog. The Product Backlog contains enough work for one day or maybe two days (ie, one or two Sprints). Imagine also that a ‘whole product’ (however we define ‘product’) or release can be completed in one or two days, (one or two Sprints) or less.

With the Sprint length of only 1 day, we might have ‘Daily Scrums’ every hour (e.g., over an 8 hour day). The Sprint Planning Meeting might last 20 minutes. And the Sprint Review at the end of the day might last 10 minutes. The Retrospective might be 10 minutes.

Short Scrum would be useful when a Team has lots of small things to do, and those things are changing quickly (e.g., daily, and maybe being identified during each day). (For now let us assume that the Team is the ‘ideal’ size of 7.) And you want feedback quickly (each day). The Team can build ‘working product’ (something that can be demo-ed that is in some sense complete) in 1 day most of the time.

Obviously ‘Short Scrum’ is a special situation or set of situations. There may be many situations in the US (or the world) like this, thousands or millions.

Obviously, some situations might be similar, but not exactly these numbers.

Getting feedback every day can be enormously helpful.

One classic example is a small family doing a set of chores over the weekend.

This model also implies a high level of interaction in the team, during the day.

The concept of ‘long term planning’ has little meaning. Long term planning might be planning for the week. Note that Scrum (the simple framework) does not mandate any Release Planning.

The Velocity concept might be minor or not there, if it is not useful. For example, if the Team is taking on a different type of work each Sprint (each day), then Velocity is unlikely to be consistent. Since a ‘release’ is happening every day, there is probably less need or no need to have the forecasting knowledge that velocity can give the Team. But, in terms of continuous improvement and perhaps for other reasons, velocity might still be useful.

Few or none of these ‘criteria’ are ‘hard and fast’, but one certainly can imagine situations like this.

Long Scrum

In Long Scrum, imagine the Sprint is 2 weeks long. Imagine it will take several Sprints (e.g., 8) to complete the product (meaning: release the first release of multiple releases).

The Product Backlog might be very long (e.g., 6 months of work or more), and might include items that we might never get to.

The Sprint Planning Meeting might be as long as 4 hours (although usually somewhat less), and a Sprint Review might last as long as 2 hours (if useful). And the Retrospective might last 90-120 minutes, and of course help the Team increase their velocity.

We have the ‘normal’ 15 minute Daily Scrums.

This type of Scrum is more useful when the Team has a big mountain to climb, and has some understanding of the mountain beforehand. (The mountain is a ‘product’ with a decent vision of what the product will become. The product is anything that that Team might ‘build’… tangible or intangible, physical or electronic or ?. But we do want the pieces to be demonstrated.)

Imagine that the Team has the work divided into 8 small pieces (small stories) for each Sprint. And it takes some time to get each piece to be working. At the end of 2 weeks, all 8 pieces can be working.  It is useful to get feedback from business stakeholders: ‘do you want what we have built so far?’  The right people will come every 2 weeks (in part because we have built enough to interest them).

The Product Backlog might still be changing, but the basic scope of the product is not usually changing a lot, or at least we do not expect it to change that much. We think we know what to build each Sprint, although in the Demo we sometimes discover that the business stakeholders do not like some pieces (some stories).

In this situation, the concept of long term planning (well, planning over the 6 months, which would definitely seem ‘long term’ to the Short Scrum team)… is useful. And needed. Necessary in part, because the business, the customers and the marketplace require some prediction of when the product will arrive or that ‘it’ will arrive by X date. Time is key in this way.

So, Velocity is needed. And more do-able, in part because the work is relatively more consistent.  The Team needs to stay together, so they have time to discover their real velocity.

***
I have three main points in describing Short Scrum versus Long Scrum.

1. Scrum can be played many different ways, and yet all can be called Scrum.
2. Some of you will mainly be playing Short Scrum…where the work is changing frequently and identified only a few days before it is done.
3. Short Scrum can seem very different than Long Scrum (to both sets of people), and yet both are Scrum. There are also, of course, varieties of Scrum that are some hybrid of short and long.

Hope this is helpful.
Your comments please…

« « Balancing the work in the Sprint (coding vs testing) || Scrum requires Effort » »