Sprints (Scrum)
Sprints are a core concept of LDP/600 Resources/Scrum (Agile). Sprints themselves are iterative, short time-boxed periods for completing a defined set of of work. Typically they last 2 weeks, but can be longer up to a month.
To effectively Sprint, one should focus on results, not on the immediate micromanagement of work. You should learn by doing, learn from that, and feed that knowledge back into the system and improve.
All Sprints follow the process shown below.
!LDP/600 Resources/scrum_process_atlassian.svg
Sprints utilize all LDP/600 Resources/Ceremonies (Scrum).
Sprint Review
A Sprint Review comes before and is separate from LDP/600 Resources/Ceremonies (Scrum). It’s meant to showcase the finished work in a casual maner, as if they were general consumers. It’s the time to ask questions, try new features, and give feedback. It’s loosely a Ceremony, but not quite due to it’s informal nature.
In order for a Sprint Review to begin, work for this ongoing Sprint must be considered Done. The definition of Done is dependent per Sprint and should have been clearly defined during LDP/600 Resources/Ceremonies (Scrum).
Sprint Reviews are recommended to last 30m to 1h for each iteration(?).
This process should be a postiive reinforcement on the team’s morale, as it is a time to celebrate sucess. If this is not the case, it may be a sign of:
- too much work
- too much existing technical debt
- unsustainable code, resulting in too many bugs
- poor workflow
- poor product owner-development team communication (e.g. product owner changed requirements during iteration)
Sprint Review will deepen product vision amongst the entire team.