Iterations (sprints)
As a Project Management method, Agile focuses on delivering Features - or Deliverables - as often as possible. As part of the definition, the Deliverable must be Completed, Tested, Debugged and Usable.
Core to any Agile method are Iterations. Iterations are fixed-length periods of time, of 1 to 4 weeks (usually 2) during which we try to accomplish a list of things or deliver certain features.
The idea behind iterations is to give the team a short term objective that creates both a sense of emergency and a feeling of accomplishment once it is completed - an addictive cocktail. Short-term, achievable objectives help to keep morale high.
Sprint Backlog:
The sprint backlog is composed of a set of top priority items chosen from the Product Backlog by the team. Once the team has selected and estimated the items, there is a commitment from the team to complete them within the duration of the Sprint, in order for it to be successful.
The objective of a sprint is to release or implement one (or many) working feature(s). The team will therefor break user-stories into smaller more manageable tasks required for the release. Typically these tasks will take a maximum of 16 hours to complete.
User-stories (or Items)
Agile is highly customer-driven. Therefore, features are usually translated into User-Stories. A Story explains how a feature is to be used and gives it context. The proper way to write Stories is to start by:
As a [ role ], I want [ goal / need / desire ] (optionally: so that [ benefit ])
i.e. As a user, I want to search for my customers by their first and last names.
i.e. As a non-administrative user, I want to modify my own schedules but not the schedules of other users.
The Product Owner is responsible for writing clear and concise user-stories usually following the "INVEST" method : Independent, Negotiable, Valuable, Estimable, Small, Testable.
Product Backlog
The Product Backlog contains the list of the customer's requirements, prioritized, typically by business value. This list is broken down into smaller items or user-stories.
The Product Backlog regroups all the remaining Stories for a given project. It is meant to be properly maintained and prioritized. Once an Iteration is completed, stories are selected from the Backlog, based on Priorities and are sent to the new sprint.
Ideally, the Product Backlog is created before the project is launched and new stories are added to it as the need arises or if epics need to be broken down. Stories in the backlog should have been roughly estimated by the Product Owner.
The team contributes to the backlog by properly estimating Items and User-Stories, either in Story-points or in estimated hours. Some teams relying on Story points play "Poker Planning" to ease the estimation process.
Story Points
A story point is an arbitrary measure of effort used by Scrum teams. It is used to accelerate the estimation of the effort required to implement a user-story. Typically, the stories vary from 1,2,4,8,16 or the fibonacci series (1,2,3,5,8,13,21,34,45).
Points are a relative value that do not directly corelate to actual hours which helps scrum teams to think abstractly about the effort required to complete a story. Teams will typically estimate the smallest story in their sprint backlog that everyone can relate to and determine it to be a 1 point story and use this as a baseline to estimate other stories.
Estimated Points and hours are so incompatible that it is recommended to use only one of them as a measure of estimation. Agencies usually are required to log time in order to bill their clients. In this case, logging time and estimating in points is a correct method.
Comparing point velocity between teams is almost impossible and should not be attempted since its measure is arbitrary - a bit like comparing apples to oranges.
Iteration Review
The iteration or Sprint review gathers together the Scrum Team, the Scrum Master and Product owner.
The objective of an Iteration Review is to provide a realistic report of the team's progress to the Product Owner. It is also an excellent opportunity for the team to get feedback on the User Stories delivered to the customer.
Finally, it is a great tool to understand what happened during the sprint, if stories were under estimated and if the team has been able to keep to its commitment. This allows the team, Scrum Master and Product owner to learn about the team's capacity and improve their estimation accuracy.
The typical format of the Iteration review:
- Review the Iteration theme and goal
- Rexamine the Sprint backlog and its user-stories; has the scope changed? Was anything new introduced? How can we avoid these in the future? Was something not completed? Why?
- Demonstrate User Stories and determine whether the objective of the User-Story was achieved or not. (Accept or Reject) Were there any changes to the user story? Was it split or merged?
The Iteration review is usually followed by the Iteration kickoff.
Iteration kickoff
The Iteration Kickoff meeting usually follows the Iteration review meeting and on the last day of a Sprint, in preparation of the next Sprint.
The objective of the meeting is for the Product owner to present the Scrum team and Scrum Master with the top priority features to be released. It gives an opportunity for the team to ask questions and clarify the user-stories.
Together, the Scrum Team and Product owner will decide on a Theme and Goal for the upcoming Sprint. The Scrum Team will then proceed to estimate these top priority items in order to select how many items they can commit to. Although there can always be negotiation between the team and the Product Owner, only the Scrum team can commit to.
The success of the Sprint will be determined during the next Iteration Review meeting, at the end of the upcoming sprint.
Commitment
At the end of the Iteration Kickoff, must come the commitment. Once planned and estimated, each individual within the scrum team must be willing to commit to completing the User Stories in the Sprint Backlog.
In order to do that, one must understand the binding nature of a commitment. A commitment is a contractual binding pledge the team is taking together.
Committed teams tend to go the extra mile to get things done as was agreed. They are highly motivated and engaged and their members are strongly bonded towards a mutual objective. A "the total is more than the sum of its parts" kind of alliance.
Before committing the team and Scrum Master should make sure that:
- The stories are NOT under estimated;
- Individuals are accepting responsibility for the stories;
- They can keep the scope fixed for the duration of the sprint;
- They can be protected from external influences;
- They can keep focused on the objectives at hand.
Burndown
The burndown is one of the Hallmarks of Agile reporting. It is a great yet simple visual progress indicator of the work that remains to be done in the sprint, day-by-day.
During the sprint planning meeting, the team will identify specific stories from the backlog and estimate the tasks that must be completed in order for the sprint to be successful.
A sprint is successful if all the user-stories in the backlog are completed by the end of the sprint.
As stories are completed the remaining work to be done is burned down and gives the team visibility (motivation and commitment) on the progress of the sprint.
Having a trendline on your burndown can help visualize whether or not the team is on track towards completing all the stories in time.
Agile Roles
There are 4 typical roles in Agile. Product Owner, Project Manager, Worker and Stakeholder.
- The Stakeholder is usually the instigator of the project or the investor.
- The Product Owner is the Stakeholder's representative. He is in charge of prioritizing the Backlog and Writing the User-Stories.
- The Scrum Master is a facilitator to the team. He organizes the team, removes impediments, oversees the process, manages the Sprint backlog and the overall progress of the project.
- The Workers or Scrum Team are the ones getting things done. They estimate the stories in points and the tasks in hours. If the stories are estimated to be too big for a sprint, they can request the stories to be broken down by the Product Owner.
Self-organization
Teams are asked to organize themselves by creating the tasks related to the stories and estimating them, whether it be by Estimated Hours or Value Points. They subsequently assign tasks among each other and launch the iteration.
Daily (scrum) Meeting
The objective of a daily meeting is to provide a status and progress update to the rest of the team. These meetings are held daily and should last no more than 15 minutes. Standing up usually enforces that rule.
During the stand-up meeting, each team member is encouraged to answer three questions:
- What was done yesterday;
- What will be done today;
- Am I blocked or do I foresee any Impediments.
Daily meetings are an efficient way to promote commitment and track if the team is able to fulfill its commitment.
Releases
Releases are a part of the Grander Scheme of things. A release usually consists of a few iterations, where many Features or Deliverables are sent to the client or put into production.