There are many events in product management and ‘Sprint’ is one of them. Each event in Scrum is a formal opportunity to inspect and adapt Scrum artifacts. Events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum.
In fact, Sprint is a container for all other events. As the name implies, a sprint is all about getting things done swiftly and efficiently within a short period of time. Each Sprint may be considered a short project. This demonstrates the agility of Scrum: build quickly and fail quickly to develop successfully. If you didn’t get the outcome you were hoping for, your cost exposure is just those two weeks and nothing else.
The sprints are back-to-back. There are no gaps between 2 sprints.
Input of a sprint: we need a DEEP product backlogs, which will be described in another post.
Sprint artefacts
Sprint backlog
Sprint goals
Output of a sprint: an increment – a potentially shippable product. Each increment is additive to all prior increments and thoroughly verified, ensuring that all increments work together. In order to provide value, the Increment must be usable.
To measure the sprint performance, we can apply various practices like burn-downs, burn-ups, or cumulative flows. I’ll discuss these methods in other posts.
How to determine sprint length
Sprints are fixed length events of one month or less to create consistency. Normally, the sprint length would be 2 weeks. It is the Scrum team who decides the sprint length (PO, Scrum Master and the development team).
The length depends on the following factors:
The agility/uncertainty of the industry: if the market is changing a lot, the product also needs to update on a more regular basis. For example, the e-commerce products are changing much faster than the banking ones.
The product stage: at the early stage when most of the things are assumptions, the product team needs a short build-validate cycle. In contrast, a mature product such as Microsoft Office doesn’t need to update the feature on a 2-weekly basis.
When a sprint is too long, the Sprint Goal may become invalid, complexity may rise, and risk may increase. Shorter Sprints can be employed to generate more learning cycles and limit risk of cost and effort to a smaller time frame. After all, just like building a feature, your team need to experiment with the sprint length and change it till you have established a rhythm.
Pros and cons of shorter sprints
Pros
Teams have better opportunities to make smaller changes.
Frequent sprint reviews allow product owners more feedback and frequent opportunities to update their thinking.
Slowdowns and impediments are highlighted more quickly since the team should complete all the features by the end of every sprint cycle.
Short sprints make planning easier.
It lets teams do a better job, boost visibility and understanding of processes within a sprint.
Cons
It is challenging to finish a product by the end of week two.
It can be stressful for many teams.
People are against sprint meetings for one-week sprints. But, they should increase gradually as the sprint length increases.
A few rules
According to the Scrum guide, during the Sprint:
No changes are made that would endanger the Sprint Goal. If there is a big change that make the sprint goal obsolete, the sprint will be canceled by the PO
Quality does not decrease. It depends on the Definition of Done (DoD) of the product. We do not release the new features until the DoD is met. One misunderstanding is we have to release every sprint but it’s not the case. The output of a sprint is an increment – a potentially shippable product, not a release. We do have a separate release plan.
The Product Backlog is refined as needed
Scope may be clarified and renegotiated with the PO as more is learned. A big misunderstanding is we have to clarify all tickets before beginning a sprint. However, we can start a sprint with enough clarified tasks. During the sprint, the PO can continuously provide more details as more is learned.
