Start your sprint

As described in the Scrum Guide, a Sprint, is a time-box of 1 to 4 weeks during which a “Done”, usable, and potentially releasable product Increment is created. All sprints have to keep same duration from beginning to the end of project. A new Sprint starts immediately after the conclusion of the previous one.

The sprint is launched during the sprint planning. It brings together the development team, the Scrum Master and the Product Owner. Together, they will define the next increment that will be developed during the sprint.

The Product Owner (PO) begins with the presentation of the highest priority user stories (US) by emphasising their business value.

In summary, user stories that could potentially be addressed during the sprint. The PO must ensure that these stories are complete (all of the Product Backlog columns are filled in) before the meeting. The number of stories presented depends on the product and the velocity of the team. The PO may present a few more stories than necessary.

YOUR BEST AGILE USER STORY A reminder on how to write googd US.
easyBacklog An intuitive time saving backlog management tool for Agile practitioners working in or with agencies.

In "traditional" project management, the load is estimated by the "number of days" multiplied by the "number of resources".

In SCRUM, we speak rather of (points of) complexity, which reflects the complexity regarding realisation, time and risk. The ability of the team in complexity points on a given sprint is called velocity.

Complexity is an eminently subjective concept. Some teams will find themselves engaging 200 "points" of complexity on the sprint and others will engage 30, but that does not mean that one works more or better than the other. It depends not only on the perception of the complexity points, but also on the granularity of the user stories and tasks, team experience, working environment and the type of project.

Complexity is simply a measure like any other, and its evolution over sprints (with a constant team size) may reflect improved team cohesion, or on the contrary technical or organisational difficulties.

The highest priority user story is split into development tasks. Whenever possible, a development task should be as short as possible and involve only one type of expertise. The Scrum Master ensures that all team members have understood each task and writes it on a Post-it (or on a trello card).

When the User Story (and all its validation conditions) are 100% covered with a set of tasks, we can move on to Planning Poker.

So, this activity consists of estimating each user story in complexity points. It takes its name from the fact that each participant has a deck of cards face down, each indicating a value, most often calibrated on a sequence of Fibonacci (0, 1, 2, 3, 5, 8, 13, 21...).
Don't worry, there is no stake. Unless you start a Strip Planning Poker!

The User Story is taken one by one, and each member of the team places a card, faced-down in front of them, representing their estimate of complexity.

There are applications that simulate Planning Poker, but it's possible to easily create a DIY game.

When everyone has prepared their estimate, they turn the cards (NB: we can also vote by raising hands). If the estimates are consistent, the broadest are selected. If a participant gives an estimate that is very different to the others (more or less), it's possible that they may have considered an important method for the realisation that nobody else has, or they have experienced this ideal and knows the pitfalls. The other reason may be that they misunderstood the task. Nevertheless, it is always interesting to hear their point of view. In the worst case, we can restart a round of debate and hold a vote.

We can agree on a convention. For example, a story rated between 0 and 1 will be trivial (change of a label, a config) and may take less than half a day of work. A task rated 8 or more (wide scope, requiring the intervention of several specialists, and/or with risks) poses the risk that the story will not be completed by the end of the sprint, and this means that it should be reviewed and recreated as a smaller user story.

What to do if we do not know how to estimate.

It is usually very difficult to know exactly at what pace we work on any given task, and it is even more difficult to estimate the velocity of a team. There will most likely be mistakes when attempting to estimate, however this is common and will improve over time. Try to estimate as best as you can and adjust it for the next spring. Although there is room for mistakes, a professional team should avoid being overly optimistic in their estimates because the commitment to the client to deliver what is put in the Sprint Backlog must be considered.

NOTE: Although it may be tempting to use time instead of complexity, which is a more abstract notion at first glance, it is recommended that you and your team play the game using complexity.

Once everyone agrees on the complexity to assign to a user story, we can update the story estimate on the product backlog and then move on to the next user story.

If the sum of sprint story estimate: is about equal to the velocity eligible for the sprint, we can go to step 6 still allows you to add another user story, add it and go back to step 3.

Once the user stories for this sprint have been selected, all that remains is to set up the Sprint Backlog and Burndown Chart. Both documents will serve as a meeting record and will be updated throughout the sprint.

In Agile culture, artifacts are the documents and tools put in place in order to run the method smoothly and efficiently.

Sprint Artifacts include the Sprint Backlog and Burndown Chart.

Sprint Backlog

The Sprint Backlog, sometimes called Kanban by abuse of language, is most often in the form of a table consisting of five columns, i.e. Stories, Todo, Doing, To be reviewed, Done. It must always be visible and accessible to the team, and should be updated during Daily Scrums.

The first column lists the sprint stories. We generally write the title of the story on a post-it as to avoid too much detail on a small piece of paper. At the beginning of the sprint (at the end of the sprint planning meeting), tasks are placed in the Todo column in front of their corresponding user story. Each developer then chooses a task by writing their initial on it and placing it in the Doing column.

At each daily scrum the estimates of the remaining work for current tasks are updated, and the post-its are moved to the appropriate column.

Burndown Chart

This graph represents the amount of residual work in the remaining time. It is usually displayed on the wall next to the Sprint Backlog.

When creating the document at the start of the sprint, draw a line that represents the ideal amount of work remaining at any given time. For the point corresponding to the start of the sprint, represent the total amount of work planned for the sprint, for the point corresponding to the end of the sprint, there should be no more work left.

At the end of each Daily Scrum, once the Sprint Backlog is updated, we add up the estimates of all the tasks that are not in the Done column. This number indicates the amount of work remaining.

Sprint Artifacts !!

Once you are satisfied that you have followed all of the best practices that we touched on in this quest, post your solution. If you feel you haven't quite met the requirements, work together to correct mistakes before uploading your final solution.

If the SCRUM method has been adapted to the quest, explain the adaptations in a text file of your Gist. Specify whether these adaptations have come from the trainer or from discussions amongst your project team.

Post-its are legible The Sprint Backlog contains the required columns - Stories, Todo, Doing, To be reviewed, Done All tasks are estimated and their complexity is reasonable Todo column tasks are not assigned All tasks that are not in the Todo column are assigned to a developer Tasks relating to the first story are more advanced than the others The abscissa of Burndown is measured in days The ordinate of Burndown is measured in points of complexity The ideal progression as well as the actual progression (if the sprint has started) appear on the burndown All criteria which has not been added is for a good reason and explained in the text file