Understanding and Apply Scrum [P7]: Done - Myth 3: in scrum, releases are done only at the end of the sprint Flashcards
1
Q
Why DONT we only release at the end of the sprint?
A
inflexible and reduces speed —> goes against core of Scrum - if teams can release earlier than they should do so
2
Q
How is completeness of an increment defined in Scrum?
A
- defined by the amount of time that is still needed to get the increment to users e.g. to production
- the more time needed, the less Agile an org is
3
Q
What is needed for a team to release earlier than the end of sprint?
A
- approval from PO
4
Q
How does the scrum guide define an increment?
A
- sum of all the PBIs completed during the sprint
⇒ can be a package of new features to deploy in one go at the end of a sprint OR also sum of functionality that has been released during the sprint
5
Q
Possible origins on the myth?
A
- definition of increment
- “potentially” word - e.g. “potentially releasable product increment”
- distinction between scrum and DevOps - someone argue that DevOps is superior as it allows teams to release faster
6
Q
If we release before the end of sprint, what happens to the sprint review?
A
- Still applies, and repeat if there is more work done after the early release
- inspect and adapt still, and even better as stuff released early is in the release to production state and can get feedback
7
Q
What are some tips for SMs to coach the team about releases?
A
- coach team to continuously expand their DoD —> help them reduce the amount of work left to do after they consider it done (e.g. testing, quality assurance, release, docs)
- invest in learning about DevOps and its associated practices (automated testing, infrastructure as code, virtualization, CD) - enable faster releasing without compromising stability and quality
- use sprint review to gather feedback on delivered increment, business conditions and promote collaboration
- reflect on amount of work that needs to be done AFTER a team considers and increment “done”
