After experiencing a few sprints, the sprint planning sessions might be long or disorganized with time spent figuring out which story to include or not (right sized and pointed). It might be wise to consider adding the process generally known as backlog “grooming”.
Acceptance Test
An acceptance test is a test that verifies that the story respects the Product Owner acceptance criteria. These acceptance criteria should be included with each story as early as possible in a Sprint, or before taking the story in sprint is ideal. Using acceptance criteria is essential to confirm a team-wide understanding of each story. For teams who have automated testing setup, it is recommended to automate the acceptance test cases so that the status of the story can be verified anytime in the future by simply running its acceptance test.
The purpose of story points is to give stories a rough size estimate. Story points are not supposed to be precise, so it’s recommended to use a scale like 0, 1, 2, 3, 5, 8, 13, 20, … Even though the scale is rough, if the team is consistent in assigning the same number of points to stories of similar size, their velocity (number of points completed per sprint) will tend to stabilize over time.
There are a number of backlogs represented in the agile Scrum process that all represent work required to enhance a product, but have slightly different context.
A key benefit of Scrum is the use of simple visual representation of progress called burn-down charts. When it comes to reporting the status of a project or product road map, it's important to have one version of the truth. Many people in an organization need to communicate dates and the status of these dates and the Scrum makes it very easy on a daily, weekly and monthly basis to represent an accurate view of the work in progress.
We will soon be adding in this section more information about the Release Burn Down and Sprint Burn Down.
Stories provide a light-weight approach to managing requirements for a system. A story captures a short statement of function on an index card and/or in a tool. The details are figured out in future conversations between the team and the product owner or customers. This approach facilitates just in time requirements gathering, analysis and design by the following activities:
Although many people assume at first that Agile methodologies remove all types of documentation, this is not the case. Heavy requirement documentation, which is usually inaccurate, incomplete and outdated the second it gets signed off, are replaced with user stories. These are the starting point for any work and provide a lightweight approach at gathering requirements. You will find below other items that cover the necessary level of documentation in Agile and that are referred to as artifacts.
The retrospective is an internal team meeting designed to look inward at the process and organization. It is designed to help the team self-facilitate the process and assure that they are adapting to changing environments and seeking to improve. The goal of this session is to promote continuous improvement in how the team does the work and provide more value to the rest of the organization.
During the sprint, it’s extremely important for the team to work collaboratively to best achieve the sprint goals. The daily scrum meeting is an important mechanism for the team to synchronize their work, remaining informed about the work being done across the team and raise impediments to be addressed.