As part of our commitment to excellence and innovation, we’re constantly developing, testing and launching practice-proven features to help your organization stay and scale agile. Therefore, more exciting features will be launched soon. See our upcoming features in the list:
Tips & best practices:
Why a 1 week sprint is much more effective and increases the team velocity enormously!
Scrum organizes the added value in iterations, known as Sprints. Sprints in Scrum are initially nothing more than time boxes, i.e. just one-time units. Nothing more, but also nothing less.
Thus – and this is the interesting aspect of Scrum – Scrum introduces a different paradigm of time management.
Waterfall also has certain phases like specification phase, implementation phase, test phase, documentation phase, acceptance phase, etc.
Here, however, the time periods are bound to specific content, and the content ultimately determines the length of the time period. The phase is completed when the objectives of this phase have been achieved, or at least when satisfactory results have been achieved.
Scrum turns the relationship between timebox and content upside down. The timebox, i.e. the length of the Sprint, is clearly defined and should change as rarely as possible. We’ll get to that in a moment.
The content, or more precisely the scope, that is to be delivered in this timebox is variable.
At first glance, this paradigm shift seems to be necessary because of the vertical (end-2-end) and feature-oriented development that Scrum introduces. But the decoupling of timebox and scope gives Scrum teams even more opportunities.
The decoupling of the timebox and scope offers much greater flexibility. When choosing the length of a Sprint, other things can suddenly be taken into account than just the scope.
The Sprint length thus becomes more of a strategic tool to better support the flow of value. The following example illustrates this:
Apart from bugs, constant scope changes in the middle of a Sprint are not only a nuisance for Scrum teams, but they are also very expensive and a real velocity killer.
Cross-functional teams have made a lot of effort to perfectly balance a Scrum Sprint during the planning, which takes several days of effort (not time) over all team members, taken together with all activities.
A scope change immediately destroys this balance; a replanning is necessary, which costs money.
Teams that are constantly faced with scope changes could reduce the length of the Sprints to one week, for example, or even just for one phase.
In the meantime, the Scrum Master can work with stakeholders to address the causes of permanent scope change, whatever they may be.
The Sprint construct is used here as a strategic instrument and is not only the carrier of the scope.
If you ask me, the optimal length of a Sprint is not two weeks, but only one week.
This is not only because the risk of expensive scope changes is at its lowest here, but also for a number of other reasons:
Scrum is a difficult matter, no question. So we should use all the help we can get to make things easier, not harder. We know the weekly rhythm almost from birth and therefore it is relatively easy for us to plan the period of one week accurately.
The shorter the Sprint, the shorter the Stories need to be. Personally, I’ve seen many teams that are really annoyed by Product Owners who love writing mammoth Stories. I’ve seen extreme cases of two Stories for a three-week Sprint with a team of seven. Short Sprints force the PO’s to write short Stories.
I also know teams that have been doing a pretty relaxed job in the first week of the two-week Sprint, according to the motto “we don’t have to deliver until next week”.
Try scagile now and see what your Sprint Backlog could look like.
The preference for longer, at least two-week Sprints is usually based on the erroneous assumption that less time will be lost in longer Sprints for meetings (Planning, Review, Retrospective) and more net value-added time remains.
My experience tells me the opposite.
Planning long Sprints takes longer and is much more tiring.
Scrum.org says planning a four-week Sprint can take up to 8 hours. Seriously, who wants to sit in an eight-hour technical workshop? And who expects something meaningful to come out of it?
In short Sprints, meetings are more frequent but much shorter.
For example, a Retrospective can still be held every two weeks. There isn’t that much to improve every week anyway and to improve significant things you often need more time.
The mission is to tickle 4.5 days of net development time out of a 5-day Sprint. And that is possible.
As a matter of fact, shorter Sprints create even more transparency and demand even more discipline. Otherwise, you won’t get 4.5 days of net value-added time.
But that’s exactly what teams often don’t like that much. Often, Dev Teams and POs like to stay at a distance and don’t have the best of relationships. During short Sprints, they have to communicate more often and more directly with each other.
The Scrum Master also has to work more intensively with the team to keep the pace up.
Agile transformations always feel a bit like therapy, at least that’s how they are often organised by agile coaches, and the patient doesn’t always feel better after the therapy.
Kanban or Scrum – which one is most suitable for your team? A question as old as time (sort of). Here is what Kanban is all about and how to decide which framework is the best for you.
The essence of Scrum: Just ask yourself which of the C’s is involved in your Scrum process and you will find it easier to estimate the impact and make better decisions!
Where value flows & business aligns –
The first AI-powered scaled agile project management tool.
