Agile Scrum and WAPP

Purpose of this document

The following describes the SCRUM standard applied by our development group. It is important to remember that the methodology is very flexible, so what is stated in this document is only a guideline; everyone is free to adapt and modify this model to their own context.

Product Backlog

The product backlog is a list of the items (Product Backlog Items) needed to complete the product; it can contain stories, bugs, technical requirements, ideas and research items (Spike). It is important that the product owner can understand every item and why it is there without necessarily knowing what has to be implemented (technically).

Another important point is that the product backlog is always subject to change; gaining new knowledge about the product being developed can in fact lead to a reassessment of the priorities of the items at the top of the backlog, items that may be swapped with others further down, removed or added to the Product Backlog.

User Story

User stories describe a single feature of the system from the perspective of an end user. They should be small, so that the team can make a rough estimate of the effort required to deliver them.

Each story includes:

• ID: unique identification code of the story
• Name: a short name that identifies the story; it must be clear enough for the developers and the product owner to roughly understand what it is about.
• Importance: a value that measures how important the story is to the product owner.
• Estimate: the team’s assessment of how much work is needed to implement the story

Each story should comply with the INVEST acronym:

• Independent: It must have no interdependencies with other user stories.
• Negotiable: Stories must be “negotiable” and open to contributions from everyone
• Valuable: It must be able to bring added value to the end user.
• Estimable: It must be possible to estimate it
• Small: It must not be so large that it cannot be planned or delivered
• Testable: It must be testable and include information on how to run the tests (Acceptance criteria).

Tip:

What matters is not having absolutely correct estimates (i.e. a two-point story takes two days), what matters is having relatively correct estimates (i.e. a two-point story should take about half the work of a four-point story).

How to write user stories

Each story describes what to do, for whom and why, so that the customer and the developers understand it in the same way. The point of view is that of whoever requests the new feature, and the amount of information is the minimum the development team needs to make a rough estimate of the work required to deliver it.

Scrum provides no guidance or requirement on the format to use when writing these items, but the format that proves most useful for the purpose is the following:

As a type of user, I want some goal so that some reason

As a user type, I want a specific feature, so that value/benefit

Backlog Refinement

The goal of this meeting is to refine the backlog by reading the stories, in order to lay the groundwork for planning the next sprint. Backlog refinement lasts at most 2 hours and takes place during the sprint. The product owner defines the goal of the next sprint and identifies the stories needed to achieve it; each story is given a level of importance.

Obviously the aim is not to go through the whole Product Backlog, but only the items expected to be included in the next iteration or, at most, within two Sprints. It is the Product Owner’s responsibility to define or clarify priorities and goals.

The stories in the backlog are reordered according to the product owner’s choices (goal and importance). During the meeting, with the help of the product owner, the selected stories are read, any doubts are cleared up and, where appropriate, the stories are optimized (for example, large stories are split into smaller ones).

The Product Owner provides details and answers questions about the “why”; the developers provide details and answer questions about the “how”

Sprint Planning

“The purpose of the sprint planning meeting is to give the team enough information to be able to work in undisturbed peace for a few weeks, and to give the product owner enough confidence to let them do so.”

Sprint planning is time-boxed: it should last at most 3 hours, with a 10-minute break every hour. If the goal has not been reached, the team goes ahead with what has been analyzed (the team learns to manage its time better).

The reason why the whole team and the product owner must attend the sprint planning meeting is that the product owner is responsible for sharing scope and importance, while the team is responsible for providing the estimates; these three properties (scope, importance, estimates) are continuously refined through a face-to-face dialogue with the product owner.

In the first part of the meeting the product owner shares the sprint goal and points out the stories that, in their view, lead to achieving it; the team examines each story and estimates its time, starting from the most important one. During this process, if needed, stories are broken down into more detailed tasks (time estimates are usually easier to make when stories are split into tasks); important questions about scope may arise while the tasks are being created: in some cases the answers will surprise the team and lead it to change its estimates; in other cases the estimate is not what the product owner wanted, which may lead them to change the importance given to the story, or to change its scope (which will require a new estimate). Then, for each task, the team proceeds with Planning Poker.

When all the stories are clear and estimated and, where needed, a task has been defined for each of them, the team decides which stories to bring into the next sprint (the team decides how many stories to include in the sprint, not the product owner or anyone else). At this point there are two ways to proceed:

• The first way: the team is asked to ignore the numbers and simply consider, based on gut feeling, whether it believes it can complete the stories selected for the sprint; if it seems too much, a few stories are removed; if instead it seems too little, a few are added. The product owner can influence this process by working on the stories (they can slim them down or change their importance).
• The second way: the team’s velocity is checked and then the team calculates how many stories can be added without exceeding the estimated velocity.

Tip for the scrum master: you can combine both approaches!

If the sprint ends early

The stories at the top of the (previously ordered) backlog are evaluated and brought into the sprint

If the sprint ends with uncompleted stories

The team learns from the mistake so as not to repeat it, and the stories are moved to the top of the backlog. Whether they are brought into the next sprint will depend on the Product Owner since, in the meantime, priorities may have changed.

Team velocity

Team velocity is represented by the story points the team manages to complete in one iteration. There are several methods for calculating team velocity; we find it most effective to calculate it on the basis of man-days, assigning 2 story points to one man-day. So, assuming a team of 4 people, 8 story points can be completed per day. This value is not really effective, however, because it assumes an ideal day with no interruptions (which is rare). It would also be useful to take into account factors such as unplanned work added to the sprint, people falling ill, etc.

In fact, it will take three to five sprints to stabilize the development team’s velocity. The first sprint is generally complex. It means starting with a team whose members do not necessarily know each other. Velocity is rarely high, but it will gradually increase over the first three or four sprints until it stabilizes. Agile velocity is then optimal and relatively representative, even though it remains an estimate of the effort the team is able to produce during a sprint. Once Agile velocity has stabilized, it becomes possible to predict fairly accurately the number of story points the team manages to complete. To get a reliable estimate and therefore forecast releases more effectively, it is best to consider at least 4 or 5 Sprints.

Sprint Review

The sprint demo is a very important meeting, lasting at most one hour, whose goal is to increase trust between the team and the product owner so that disruptions and pressure decrease. In fact, it allows the team to show the product owner how attentive it has been to their requests, thereby earning credit. In addition, feedback is gathered from the various stakeholders so that the course can be adjusted as the iterations proceed.

A further advantage: the team is pushed to complete and release the increment (even if only in a test environment). Without demos, you will keep ending up with a long list of things that are “99% done”.

During the demo the sprint goal is recalled and, if needed, the product is described to people who are not familiar with it. The demo should be kept short, not pretty, and it must be business-oriented, avoiding technical details. If possible, those present (Product owner) should be allowed to try out the product features for themselves.

Retrospective

The retrospective is the second most important meeting of the iteration, because it is the best opportunity to improve, and it lasts at most three hours. Each team member might have an idea for improvement, but there is no way of knowing whether the team is willing to apply it; this meeting provides the opportunity to compare views and discuss, so that everyone can contribute to improvement.

Each team member can say what they think went well, what they think could have gone better, and what they would do differently in the next sprint.

The difference between the estimated velocity and the actual velocity is analyzed and, if there is a large gap, the team tries to analyze the causes. When time is almost up, the scrum master tries to summarize the concrete suggestions on what could be done better in the next sprint.

Poker Planning

• The development team, together with the Product Owner, meets in a room (which can also be virtual)
• The Product Owner presents a user story to the team and leaves time for questions. The goal is for everyone present to understand it and start from the same basis, so that they can reach an estimate for each of the items that make up the user story.
• The “estimation” phase begins: the first item to evaluate is chosen and each participant, individually and privately, picks a card from their deck according to the effort they consider necessary.
• After a countdown, the participants reveal their cards simultaneously: if all the cards match, that value is assigned to the item and the procedure ends. If the cards differ, the values that are particularly far from the average are discussed. So the person who gave the lowest value and the one who gave the highest must justify their choice. Once the explanations are over, a new estimate must be made. This procedure repeats in a continuous loop until unanimity is reached.

Tip:

• Stories can also be estimated by comparing them with stories already completed or estimated earlier (does it weigh the same? a little less or a little more?)
• To make estimating easier, you can assume that 2 story points equal one working day (8 hours).
• If consensus cannot be reached, you can fall back on an average.

Ideal Iteration

Through various projects and several attempts we have set up what we currently consider the ideal iteration. We have found that a 2-week sprint strikes the right balance between quality and speed. The weekly setup that seemed best to us is the following: the sprint starts on a Monday and ends on a Friday; on the last Wednesday the Backlog Refinement is held in order to organize the next Sprint; then on Wednesday the sprint is considered closed and the other meetings follow (demo, retrospective, Sprint Planning for the next iteration).

Assuming there is a defined backlog, we start with the Backlog Refinement, which lasts at most 2 hours; during this meeting the stories are reordered according to the customer’s priorities and presented to the team, starting from the first one at the top of the backlog, and if needed they are broken down into simpler work items.

At the end of the 2 hours we will have enough refined stories to organize a sprint; the remaining stories will be refined in the next refinement if and only if priorities allow. After the Backlog Refinement, even on the same day, we move on to Poker Planning, estimating the stories refined earlier; it is useful to do this on the same day because the team should have a clear picture of what it has refined and has not been distracted by other things. Once the previously refined stories have been estimated, we move on to Sprint Planning, where the team decides what to bring into the sprint to reach the goal set by the PO; the team selects the stories based on gut feeling, and it is important to make clear that it is not so serious if some stories remain in the sprint without being completed, because the team, especially in the early stages, needs to reach a level of awareness that improves that gut feeling; the scrum master can use the team’s velocity to understand whether what has been selected is realistic or not and, if needed, can influence the team’s choice. Sprint planning lasts at most 2 hours, conventionally 2 hours for every 5 days of sprint. The sprint then gets under way and every day the various Daily Meetings are held, where it is important to make every team member understand how important it is to update the team on the status of the work done. The Daily lasts at most 15 minutes; any discussions that fall outside the 3 questions should be held in other meetings with the people directly involved.

Once the sprint is over, we move on to the Review, which allows the customer to test the application and give feedback on the work done; it lasts at most 1 hour. Finally the Retrospective is held, even on the same day, where the team identifies what went well and what went badly, in order to improve the next iterations; it lasts at most 3 hours. Then we start again with the Backlog Refinement.

Pro tips

Preconditions: there is a backlog of user stories.

• Lead the customer to define several goals so as to plan a release plan.
• The PO defines a goal (sprint goal) for the next sprint (what to deliver in the next release)
• The PO identifies which stories to bring into the sprint so that the goal is reached (the sprint goal is met) and the stories are reordered.
• Refinement is done with the team: the user stories are explained and, if needed, optimized (for example, large stories are split into smaller ones). A study period is allowed for the approved stories in the backlog (1 day). Tasks are derived for each story studied.
• Poker planning is done on the tasks created.
• Sprint planning is done with the team: all the stories and tasks to be completed to reach the release goal set by the PO are brought into the sprint. It lasts max two hours per week of development.
• The sprint starts and the various daily scrums are held.
• At the end of the sprint the review is held: a demo with the customer to understand which completed stories they want to release.
• The increment is released to the customer (merges are done on main and versions are bumped according to the usual logic).
• The sprint is over. At this point a retrospective is held.