Before defining Agile Sprint, let’s just understand the difference between running & sprinting 😉 it would set the context right. Running and sprinting are vigorous intensity exercises. While they both use the same muscle groups, the difference lies in speed. Sprinting is a more powerful, faster form of running that can only be performed in short spurts.
- Running is a form of cardiovascular exercise that is performed for at least 10 minutes to be considered aerobic, using oxygen to primarily fuel your muscle cells. During competition, popular running races include the 5k, 10k, half marathon and full marathon.
- When sprinting, a runner maintains his full speed for the entire run. In competition, sprint races include the 100, 200, and 400 meter dash and are typically run in less than 60 seconds. When you begin to sprint you cross into an anaerobic zone and use glycogen rather than oxygen to fuel your muscle cells.
Note: The buildup of glycogen produces lactic acid which makes you quickly feel fatigue and, in some cases, a burning sensation in your muscles. This is why a sprint cannot be held for long distances or duration.
Now that we know the basic difference – let’s define Agile Sprint. Today, Agile Sprint is one of the most popular terminology in software development & testing projects world-wide!
Agile Sprint | The Scrum iteration
Scrum, the most popular agile framework in software development, has at its core the agile sprint — the scrum term for iteration. It is a short, consistent cycle no longer than four weeks. The goal is to have an iteration short enough to keep the team focused but long enough to deliver a meaningful increment of work. The agile sprint begins with Planning and ends with Review & Retrospective. Each day of the Sprint is marked by a brief meeting called the Daily Scrum or simply, Stand-up.
Agile Sprint is always short: normally about 2-4 weeks, plus they begin and end on fixed dates. There are no extensions. During each sprint, a team creates a potentially shippable product increment, no matter how basic that product is. No changes can be made to the Sprint Backlog that would endanger the Sprint Goal. No additional work should be brought into the Sprint unless the Sprint Goal has been reached or a feature emerges of such high value it must be brought into Sprint.
A core principle of the agile sprint is its cyclical nature: The sprint, as well as the processes within it, repeats over and over. Sprint Start >> Sprint progress >> Sprint End >> Repeat!
Sprint planning meeting: Every agile sprint begins with the sprint planning meeting, in which the Product Owner and the team(s) discuss the WHAT & HOW for a particular sprint – which user stories will be moved from the Product Backlog into the sprint backlog, i.e. exactly what work will be accomplished during the sprint. The goals are established & identified, and broken down into smaller and concrete tasks. Then implementation begins.
The scrum team builds and tests a functional part of the product until the product owner accepts it and the functionality becomes a potentially shippable product. The team develops code and automated tests simultaneously, ideally using techniques such as Test Driven Development (TDD), pair programming, and continuous integration.
- Daily scrum (or daily stand-up meeting): update project status, discuss solutions and challenges, and broadcast the progress to product owners. Organize the day by reviewing what the team completed yesterday and what it will work on today. Essentially, it helps in self-organization of the team and inspect the progress toward the sprint goal.
Use a review & retrospective meeting to assess performance and plan necessary adaptations.
- Sprint review meeting: The team demonstrates the potentially shippable product increment to the Product Owner and everyone else who’s interested. It also allows the Scrum Product Owner to check if all of the committed items are complete and implemented correctly.
- Sprint retrospective meeting: What was good during the Agile Sprint, what should continue as it is and what should be improved? It gives the team a chance to discuss the sprint and think of better alternatives to do things efficiently. Reflect on how things went and what they’d like to change.
Don’t just run, it’s a 100m SPRINT!
Agile Sprint: Working within the boundaries of such an accelerated time-frame, the team is able to focus on and build the most essential functionality only. Placing an emphasis on working code motivates the Product Owner to prioritize a release’s most essential features, encourages developers to focus on short-term goals, and gives customers a tangible, empirically based view of progress. A win-win situation for all!
So what are you waiting for? Don’t just run, SPRINT!