Scrum: Feature-boxing of Sprints

In certain scenario, a scrum project could allow different length of Sprints and still satisfies Timeboxing principle. It benefits an involving software product of build MVP, increase integration quality and make members even more focus.



Time-boxing is one of fundamental practices in Scrum methodology. Most of actions in scrum are time-boxed. It makes sure the project keep going and also lets members focus on current task.

Time-boxing is one of the cure of Parkinson's Law of Triviality for all kind of meeting. No matter it is Sprint kick-off or daily standup. I believe it should apply to not only project management but also other area of organization, as long as the timeframe is a consensus of members. 

You can easily find the definition or discussion of how important time-boxing (or timebox) is in google. For example: this one or this one.

Timeboxing in Sprint

A Sprint in scrum also apply to time-boxing. Normally it means when project kick-off, all scrum members will decide how long is a Sprint. The recommended length is 4 weeks in software development. After that all Sprint will be in 4 weeks, no matter how many stories have done or what changes happened between Sprints. That also means if a project is in Sprint-11, 40 weeks was gone. 

A fixed timebox sprint make process happens. But is it necessary to keep the same length of Sprint?

Still timeboxing but flexible in next Sprint

Timeboxing is still critical and should be applied in the moment before event start. Sometimes, we should not fix timeframe in project kick-off and keep for next 40 weeks or more.

In fact, every Sprint kick-off meeting should also discuss a timeframe of this specific Sprint.

Image a sprint-kick-off meeting. Everybody: Product Owner, Scrum Master, Scrum Members were together in this Sprint kick-off meeting, discuss stories and story-points. If PO select 3 stories: P1, P2 and P3 which needs 2 weeks, 1 weeks, 3 weeks. What team should do? The general practice should be keep P1 and P2 in this Sprint and also select a few lower priority task to fill up that one left week. However, there are a few drawbacks in this situation. Firstly, remember Parkinson's Law? members might extends the time for not select lower priority tasks which sometimes is not a bad idea. But secondly, if a scrum team keep doing select a lower priority to fill up time slot, it make the "priority" not "priority" any more. 

If all members have consensus of flexible Sprint length, they can easily setup next Sprint to 3 weeks. And that Sprint will done  P1+P2. Or with Product Owner's agreement, they can setup next Sprint to 6 weeks to complete all P1~P3. 

In some scenario, the most beautiful way should be keep P1 in next sprint only. And this Sprint will be just 2 weeks. 

Make MVP possible

Why do one story at one Sprint is a beautiful way? Well, in some scenario, we need to make MVP(Minimum Viable Product)...and keep make MVP for a while to identify market and make sure minimum waste. Unfortunately, no body can foresee the future. A quick/early delivery is the reason why MVP is useful and also the reason why it is good to stick a single story delivery in a single Sprint. To achieve that, we need flexibility in different Sprint.

The key person of MVP is Product Owner (PO). And to make MVP possible, the bottom line of scrum is to have PO's real participant. In reality, it is very very hard to PO to focus on what he needs to do. A single story delivery forces PO to make a decision of the real priority of backlogs. Since the team will really delivery a things in every Sprint and of course PO should then put the thing in the market. PO can't say: well, it is too early to go for market. Since this is his priority one! Priority one should go for market right away! 

Why Quality improved?

Very simple, each Sprint with only one story has its own QA process and due to the complexity of change is short. we can easily fix integration issue or new defeat much quicker than a sprint with more than one story.

Agile: Feel comfortable to Adopt reality

An agile team should be comfortable to adopt changes and those changes should reflect to reality. But should still keep the critical concept. There is always a way to enjoy both without compromise to an uneasy method. 

To be flexible in Sprint length doesn't mean to break Timeboxing. But it does break some rule from the regular Scrum training. Nevertheless, process is continuously improving is the bottom and spirit of Agile. Scrum master or organization leader should take responsibility to make sure the process could be tailored after retrospective.

Case Study

As developer manager of a enterprise software product, I modify a bit of product release method to make sure PO's backlog is a real priority to reflect market needs. 

The result is since 2016/July to 2017/Mar (8 Month), we delivery 5 releases. The longest Sprint is 8 weeks and the shortest Sprint is 2 weeks. We actually complete 5 major stories and achieve following technical result.

(1) Quality: no side effect in these 5 release. Compare to previous fix Sprint length model much lower technical defeat in beta.

(2) Productivity: averagely, more code conduct per engineer compare to previous fix Sprint length model. However, at the same period of time, we enjoy more team building activity then before and very very very few overtime.

(3) Motivation: engineer could see the result (no matter good or bad) few weeks after delivery. Previous fix Sprint length model needs 3 to 9 months to know if our works really matters.

If you'd like to know more detail, please drop me email.