What is a Sprint in the Agile Approach?
How do you define an agile sprint? The definition of an Agile sprint is one that’s pretty straight forward, unlike other parts of the framework that enjoy the occasional debate, such as “Sprint Zero”. The Scrum Guide describes a Sprint as the “the heart of Scrum” and it is one of the major activities within the Scrum framework. It is the core of the Scrum framework because time-bound sprint sessions are the only periods in which potentially, useable increments are made to a product.
It is during a sprint that an agreed upon scope of work has to be completed. This means that upon the conclusion of one sprint, another begins, until the entire software product has been built to the customer’s satisfaction.
Your first Sprint
The entire Scrum development team, including the product owner, would convene on the first day of the Sprint and carry out a planning conference. This is the first action to take place, the very minute the Sprint begins.
Preparation
Sprint planning requires adequate preparation. The most vital part of this is to ensure that the product backlog has been specified to a suitable level of detail, with assessment and approval criteria (the principle of Product Backlog Refinement). Next, the product owner is expected to have structured the work in the product backlog, and to have established a mechanism for discussing important Sprint goals with the team.
The criteria for discussing a goal should have been well thought-out during refinement, and indicated in the backlog. Also, the team should have an understanding of their capability for this Sprint. This basically means that they understand the amount of work they believe they can handle over the period of the Sprint. They may be able to use their knowledge and experience of prior Sprints to help them determine this.
Plan 1: The Deliverable Value
Every Sprint should end in a beneficial increase in functionality that is validated and prepared for instant delivery. The product owner is completely responsible for what “value” means with regard to the product, and should have arranged the product backlog in a way that ensures maximization of value for each and every Sprint.
To start off the team collectively decide which items from the product backlog should be included in the current Sprint. This is to ensure that value is delivered at the end.
To effectively achieve this, the product owner, working with the development team, will decide on the most important items in the backlog which of course they should be able to complete during the sprint time frame. To help this consideration the effort required to complete each item in the product backlog should have been estimated by the Scrum team before the planning session.
You want the collection of work to be consistent, and not just an assemblage of unconnected and dissimilar items. Keep in mind that we first defined a Sprint as a time-bound opportunity to accomplish something worthwhile. For instance, by the conclusion of the Sprint a sound feature could be released, or a major problem might have been resolved.
The goal of a Sprint, therefore, is the embodiment of what we are trying to deliver in terms of consistent and incremental work. A good quality Sprint goal will let the team exhibit concentration and dedication by providing a clear focus, allow group effort and the re-scheduling of tasks so that the goal is met.
Plan 2: Work Method
A Sprint backlog is more than just a collection of work items with an expected end, or goal, in mind. It is also a plan of how that goal will be accomplished, and also how tasks are connected and executed. This can be done by recognizing and organizing the tasks that are likely to be a part of the chosen method. Effectively, the Sprint Backlog is a strategy for achieving the Sprint goal, and includes an estimate of the required work.
The Product Owner does not need to attend this aspect of Sprint planning because it is the responsibility of the Scrum team to map out this estimate at a technical level. Nevertheless, the Product Owner should be on hand, even if remotely, to respond to any and all questions the team may have, and to offer any explanation that may be required about the extent of the work. If more than one delivery is anticipated during the Sprint, this should be decided agreed with the Product Owner and reported on in the Sprint backlog.
At end of Sprint Planning, the team will have prepared a reliable estimate of the work that will be required to realize the Sprint goal. It will have defined the work plan in the Sprint backlog which the team owns. They should be in a position to start the implementation of that plan straight away with a clear understanding of exactly how much work is left at any point in time as they proceed through the Sprint period. This is called the Sprint Burndown.
Sprint Burndown
When the team has considered their Sprint Backlog they can begin work Having allocated tasks to individuals, they will never the less work together as a team, to ensure that all those tasks are fulfilled. They will be able to mark down their advancement by using their task board and the Sprint Burndown that details the work that remains.
Every member of the team must be certain to keep the Scrum Task Board and the Sprint Burndown updated, so that the information is available to others. When providing information everyone in the team is required to always be as sincere and open as possible.
Tips and tricks: See how progress is being made during each sprint with Nutcache burn-down chart.
Sprint Zero
What is sprint zero then and how is it different from your first sprint? Sprint zero can be seen as controversial in the world of software development. This is because there seems to be a discrepancy between what it is, what it should be and why it should even exist.
For now, the best way to view sprint zero is to look at it as a framework, a template for all other sprints.
At this time you will identify the users of the software and work with them to build an understanding of what they would want to see in the end product. It is a free-flowing conversation between the clients’ staff and the development team to get an understanding of the software’s user base. This session typically lasts for 3-4 days in some organizations.
You can also see this as a journey of discovery, the discovery of potential features that could prove beneficial to the product, or the discovery of an entirely new target market that was not previously considered. You may want to call this a brainstorming session and you won’t be entirely wrong.
Agile Sprint Planning
It is important to understand that Sprint sessions do not just occur. Each sprint consists of Sprint planning as described above, as well as Daily scrums. There is also the Sprint review and of course, the Sprint retrospective. These will be treated more in depth as the post progresses but at the moment we will be discussing Agile Sprint Planning.
The Importance of Sprint Planning
While developing software within an agile project, every sprint must start with a Sprint planning meeting. The primary purpose of that meeting should be to plan the sprint. Make certain that all the team members, including the Scrum Master, The Scrum Development Team and the product owner are in attendance. This meeting offers a significant chance for the Scrum Team to decide on the number and size of work items that can be included in the approaching sprint.
Sprints are usually short-lived, lasting from about eight hours to one-month and are separated into two parts: Objective Definition and Task Estimation.
Objective Definition occurs during the first half of the planning meeting where the product owner gives details on the highest priority User Stories in the prioritized Product Backlog to the Development Team. The Scrum Team in partnership with the product owner gives a clear-cut definition of the goal(s) for that particular Sprint.
Task Estimation takes place during the second half of the meeting where the Scrum Development Team come to a decision on the method that will be employed in the completion of the selected Product Backlog features to ensure the fulfillment of the Sprint goal.
As the Sprint planning meeting progresses, there is a discussion about the approved User Stories which have already been estimated and committed. All Scrum Team members produce individual brief estimates for the work tasks by means of tools such as planning poker. If these take up more time than is expected then it indicates that the User stories were not fully ready to be worked on. Every Scrum Team member will also make use of the Effort Estimated Task List to choose the activities they plan to work on during the Sprint, based on their proficiency and knowledge.
The team then reaches an agreement on the amount of work that will be included in the current sprint before the Scrum Team, headed by the product owner, gives the ‘go ahead’ to create the Sprint Backlog and Sprint Burndown Chart using the User Stories and the effort estimates produced during the Sprint Planning Meeting.
It is best for the Scrum team to try not to perform the following activities during the planning meeting. These are meant to be done to prepare the team for the sprint planning meeting.
Grooming – This assists the team in being certain that the refinement of requirements and User Stories are completed before the planning meeting starts, to ensure the team has a properly evaluated and clear set of stories that can be broken down, without difficulty, into tasks and afterward, estimated.
Updates or Revisions – This action can include modifications to initial User Story estimates supported by task creation and intricacy factors discussed during the Sprint Planning Meeting.
Basically, it is best that the team performs these actions before the beginning of the meeting because they will lead to better planning and less wasted time.
The Scrum Team Roles in a Sprint
In projects that use an agile management system, everyone on the scrum team, the scrum master, the development team and the product owner, all have their precise day by day roles and activities to fulfill.
Role of the Scrum Master during an Agile Sprint
The Scrum master is the agile facilitator and ensures maximum productivity from the development team. They do this by removing obstacles and protecting the development team from interruptions or disturbances. The duties of the Scrum Master in an agile sprint are to:
- Maintain the accepted or endorsed agile standards and routines by coaching the Product Owner, the development team and the corporation when and if necessary.
- Guard the development team from exterior diversions.
- Eradicate problems, some of which could be of an immediate nature while some potential problems may be long-term issues.
- Try to create an environment or system where the scrum team can agree and take quick decisions.
Teamwork is essential for a successful sprint. Every opportunity should be used to create greater bonding amongst team members. Even lunch time should be an avenue for team members to build relationships and groom close cooperation between them. One member might need the help of another at some point during the sprint, and a healthy relationship increases productivity.
Scrum Development Team Roles during an Agile Sprint
To deliver usable products, the following tasks are performed by members of the development team during a sprint.
- The selection and quick completion of high priority tasks.
- Seeking clarification when they are not certain about a user story.
- Collaboration with other members of the development team in a bid to agree on a design and approach to user stories.
- Undertaking peer reviews.
- Complete additional tasks as and when needed within the scope of the current sprint.
- Report progress daily.
- Notifying the scrum master of any obstacles.
- Achieving the goal agreed at the beginning of the sprint.
Roles played by the Product Owner during an Agile Sprint
The role of the product owner is to focus on the content of the product backlog for forthcoming sprints while helping the development team resolve and issues or questions they have. The Product Owner has the following duties during a sprint:
- Ensure funding and resources are available to keep development momentum at an optimum level.
- Prioritize product features.
- Be the representative of product stakeholders in the Scrum team.
- Report on the budget and schedule to product stakeholders.
- Create comprehensive user reports, helped by the development team, to enable everyone to have a clear understanding of what they are creating.
- Give prompt clarification and decisions about requirements, which will ensure that the development team continues production without delay.
- Remove business hurdles brought to their notice by the Scrum master.
- Assess performance of the complete product via user stories and provide feedback to the Scrum development team.
- Introduce any new user stories into the product backlog when necessary and also ensure that these new stories support the product vision, the delivery goal and/or the sprint goal.
- Be looking forward to the next sprint and building user stories in preparation for the next sprint planning meeting.
Organizing the Daily Scrum
On each working day, at a designated time, the Scrum Development Team will get together and agree the set of tasks they will need to complete to bring them closer to achieving the Sprint goal. This meeting is called the Daily Scrum and it ought to be as brief as possible, not exceeding 15 minutes each day.
Only the Scrum Development Team members are required to participate in the Daily Scrum, as the allocation of work is their sole responsibility. It is a limited-time opportunity to modify the Sprint Backlog as a consequence of new discoveries and lessons learned during the Sprint. The entire team participate and every team member will:
- Describe the tasks they performed the previous day to advance the Sprint goal.
- Describe the tasks they have planned for today which help achieve the Sprint goal.
- Describe any obstacles or issues they have encountered, or expect, which would delay or stop the achievement of the Sprint goal.
By the conclusion of the Daily Scrum, the development team will have a comprehensive plan for the next working day, or the next 24 hours, and also an awareness of how they will need to pool resources in order to realize it. They ought also to have a list of any obstacles which need the Scrum Master’s attention.
What is Sprint Velocity in Agile?
In software development, a system administrator is someone who gives support to a multi-user computing setting and makes sure that all services and support systems are functioning optimally.
Velocity is the name given to a forecast of the amount of work that an agile development team can productively accomplish within the limited timeframe of a Sprint.
Calculating quality is not an effortless task. An analysis of the key metrics is required, the data for which are collected during the Agile cycle to enable the team collate the information that is needed and which is used in determining when the product will be delivered.
Velocity is a functional planning tool for approximating how quickly work can be fulfilled and the length of time required to accomplish a project or Sprint Goal. This computed by evaluating all the work the development team has effectively completed during earlier sprints.
In general, velocity often remains constant during a development project, which makes it a useful measure for ascertaining how long it will take a team to finish a software development project.
Tips and tricks: Scrum teams using Nutcache can now benefit from one of the most important metrics for Scrum methodology: the velocity chart.
Agile Sprint Review
Because at the end of each Sprint a potentially usable piece of the software has been created, a meeting has to be to review and demonstrate all changes and new functions or features. This is known as the Sprint review.
If the team worked together well they will have fulfilled their tasks and achieved the Sprint goal; ensuring that all issues have been resolved and all potential risks mitigated. Primarily, the deliverable product will be of the quality and standard envisioned by the Product Owner and Product stakeholders.
The Sprint Review should also be adequately prepared for by the team. Sufficient time should be allocated for showing the completed work. Tasks may be added to a Sprint Backlog for this activity to ensure that the review aligns with the work completed and the anticipated value now delivered.
The Sprint retrospective follows the Sprint review. A Retrospective reflects on the procedure which the team is employing to ascertain efficiency. It is recommended that the retrospective be held right after the Review, because the review may raise in ideas to consider during the retrospective discussion.
The entire Scrum Development Team, the Scrum Master and the Product Owner must all attend the retrospective because they are all mutually accountable for the result of the team’s work. It is absolutely essential to have an unbound session which can get to the root cause(s) of all problems and to also identify actions which will resolve them.
A Retrospective may commence with the following statement:
“Irrespective of what we discover, it is generally understood and acknowledged that everyone contributed to their very best within the limited timeframe, based on their proficiency and knowledge, the assets made available and the status quo.”
In a “Retro”, each and every person is equal and is entitled to make their thoughts and opinions known. It is the responsibility of the Scrum Master to:
- Ascertain what aspects of the development went to plan?
- Ascertain the parts of the development that didn’t go as planned or suffered setbacks.
- Identify new ideas or concepts for expansion or enhancements to the product or method.
- Acknowledge team members who performed well or achieved exceptional results.
- Draw up a timeframe to aid people to remember significant events from the Sprint.
Sprints are like mini-projects within a bigger project; each Sprint is started with a goal and a time duration (maximum of 4 weeks) in mind. The Sprint goal provides guidance to the development team on the work to be achieved and the resultant product.
To complete a successful Sprint, it is crucial to first determine the velocity of each team as no two teams have the same velocity and it would be detrimental to think otherwise or use another team as a yardstick for determining your team’s velocity.
At the end of each Sprint comes the Sprint review meeting, an opportunity to demo and assess what has been built to ensure that the end result is in line with the overall goal of the Sprint.
