In this article, I want to provide a quick introduction into the Agile world with focus on Scrum methodology. This includes Scrum Roles, Artifacts, Ceremonies and some practical hints regarding Sprints and User Stories.
Table of Contents
Agile Manifesto was created in February 2001 by 17 software developers that met at the Snowbird resort in Utah.
“We are uncovering better ways of developing software by doing it and helping others do it; through this work, we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.”
According to the manifesto text above, the accent is put on the items from the left. As we can see also in the next chapters, to be agile means to:
- have a self organized team with better interactions and improved communication inside the team;
- focus of development to be on creating a working software that delivers business values in each iteration;
- have a real customers' collaboration in order to offer them the possibility to provide continuous feedback during development;
- be flexible and respond ASAP to scope changes.
The main Agile methodologies are:
- Scrum
- Kanban
- XP (Extreme Programming)
- FDD (Feature Driven Development)
- AUP (Agile Unified Process)
By using Agile, the projects became more successful as you can see in the statistic below:
As you can see in the statistics above, there are big improvements in the case of projects that are developed by using an Agile methodology in comparison with the projects that are developed by using Waterfall classic methodology.
In the picture above, I tried to present an overview of the entire Scrum methodology into a single diagram. You can find details about Scrum Roles, Artifacts, Ceremonies (Meetings) and Sprints (Iterations) in the next chapters.
The Scrum is an iterative methodology, and the Scrum name for iteration is "Sprint".
In the diagram below, you can see a Scrum project development split into 24 iterations for a full year's duration.
Sprint 0 – is the special iteration performed at the beginning of a project and forms the framework upon which each subsequent iteration builds. The duration of this iteration will vary depending on the complexity and existing knowledge of the desired capability. During this special Sprint, perform enough architecture and system design in order to start development and get the first Sprint started. (Additional architecture and system engineering will be performed as necessary during subsequent iterations).
After Sprint 0, all other Sprints must have the same length. This length could be between 1 and 4 weeks. The recommended length is 2 weeks.
At the beginning of the Sprint, the team will have a clear commitment on the scope, and the scope for current Sprint cannot be changed during the Sprint.
Short iterations enable Product Owners to get client feedback faster, developer estimates faster, and faster updates to plans, thereby shortening the whole feedback cycle. Any project should have at least three such occasions for stakeholders to provide their feedback before the release.
User Story (shortly US) - is a short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.
Acceptance criteria - list of activities that must be fulfilled in order to consider US done
INVEST helps to remember a widely accepted set of criteria, or checklist, to assess the quality of a user story.
- I (Independent)
- N (Negotiable)
- V (Valuable)
- E (Estimable)
- S (Small)
- T (Testable)
For a user story, the next template should be used: As a <type of user>, I want <some goal> so that <some reason>.
Epic – a user story that covers large amounts of functionality. Because an epic is generally too large for an Agile team to complete in one iteration, it is split into multiple smaller user stories before it is worked on.
Examples: Epic1 As a user, I can backup my entire hard drive, so that I can recover data after its loss.
This epic can be broken in a set of user stories:
US1 As a power user, I can specify files or folders to backup based on file size, created date and modified date, so that…
…
US12 As a user, I can indicate folders not to backup so that my backup drive isn't filled up with things I don't need saved, so that…
Playing Poker technique is used to estimate the User Stories in Story Points (SP) with the next possible values (Fibonacci numbers): 1, 2, 3, 5, 8, 13, 21. By using cards, each user story is estimated by the entire team. The estimation for a user story is made in secret by the team, then the cards are revealed at the same time and the team members with higher and lower estimates must presents their reasons for the estimation. This estimation process for the user story is repeated until the entire team has the same estimation for the user story.
Story Points - are relative values, a story that is estimated with 2 story points should be twice as much as items that are estimated with 1 story point. Story points represent the effort to develop a story and this includes everything that can affect the effort including amount, complexity and risks associated with this work.
Hint: Each User Story must:
- be created by using the above template;
- respect INVEST rule;
- have a set of acceptance criteria;
- be estimated by the team in Story Points by using Playing Poker technique.
Product Owner - is one person responsible for Product Backlog (the scope) and for prioritizing the product features in each Sprint and over the course of the entire product development.
Team - self-organizing team that includes everyone involved with the design, development, test, and delivery of the finished product. The Agile team’s goal is to deliver a quality product that meets the needs of the users.
Scrum Master - facilitates the Scrum process and creates an environment conducive to team self-organization; Can be seen as the coach for the entire team; Helps resolve impediments; Shields the team from external interference and distractions; Enforces time-boxes.
Product Backlog – is an always changing, dynamically prioritized list of requirements ordered by Business Value. Requirements are broken down into User Stories by the Product Owner. Definition of Done (DoD) at the Backlog level.
Sprint Backlog - contains all committed User Stories for the current Sprint broken down into Tasks by the Team. All items on the Sprint Backlog should be developed, tested, documented and integrated to fulfill the Team commitment.
Burndown Chart - shows the amount of work remaining per Sprint. It shows the correlation between work remaining at any point in time and the progress of the Team.
Burndwon Chart is normally generated by a SW tool, is used by the Scrum Master in order to track each Sprint and is useful for predicting when the work for the current Sprint will be completed.
Sprint Velocity - Number of Story Points completed per Sprint
In Scrum, the teams are using Dashboards in order to track the User Stories and Tasks for each Sprint and for each team member.
In the picture below, you can see the Scrum Dashboard (from JIRA tool) used to filter all open issues for a user (team member).
You can see, in the above dashboard, the User Stories and their Tasks (for this user) grouped in three categories:
Daily Scrum – daily stand up meeting of the entire team including Product Owner no longer than 15 minutes. Each participant should answer the following three questions:
Backlog Grooming - Backlog refinement meeting in order to ensure that the backlog remains populated with items that are relevant, detailed and estimated according with their priorities, and in keeping with current understanding the product and its objectives. The duration of this meeting should not be longer than 2 hours. Could have a Backlog Grooming each week and must have a Backlog Grooming before to start next Sprint!
Sprint Planning - is a time-boxed to a maximum of 8 hours for a 4 weeks Sprint. The new sprint starts with this meeting. A set of user stories from the top of the Product Backlog are estimated into story points, then decomposed into tasks and estimated in hours. Finally the Team, based on the Team Capacity, selects a set of these stories into the new Sprint Backlog (that may contain also unfinished user stories from the previous Sprint).
Sprint Review/Demo - At the end of each Sprint, a Review/Demo meeting is held. During this meeting, the Team shows what they accomplished during the Sprint. Typically, this takes the form of a demo of the new features or underlying architecture. The duration of this meeting should be maximum 4 hours for a 4 weeks Sprint.
Sprint Retrospective - meeting that helps the team to fine-tune the process. This is a time for each team member to reflect on what went right and areas for improvement. Clear action items should be defined. The duration of this meeting should be maximum 3 hours for a 4 weeks Sprint..
The main benefits of using Scrum in software development are:
- Increased product quality
- Enhanced transparency
- Increased flexibility
- Reduced risks
- Maximized productivity
- Improved communication
- Maximized cooperation
- 14th August, 2017: Version 1.0.0.1– Draft version
- 14th August, 2017: Version 1.0.1.1 – Fix the image issues and add “Dashboard” Chapter
- 15th August, 2017: Version 1.1.0.1 – Improve some descriptions, added hits about User Stories and added “Table of Content”
- 13th October, 2019: Version 1.2.0.1 - Updated some details regarding Scrum ceremonies duration
