Process

Contrary to most systems, there’s no initiation or closure in Scrum, which is considered a serious issue by some, and a feature by others. In reality, this is because Scrum targets a subset of project management activities.

At the beginning, the Product Owner talks to various stakeholders and collects a list of things to do. It doesn’t have to be a complete list, as more will be discovered as we proceed with the project. The list is called the Product Backlog.

The Product Owner is responsible for composing the items on the Product Backlog and ordering them based on their value, so that the more important ones are on the top.

Scrum has fixed-duration cycles called Sprints. Each project team decides about the fixed duration of their sprints, but it has to be shorter than one month.

Each Sprint starts with a Sprint Planning meeting (maximum 8 hours), where team members get together and the developers decide how many of the items on top of the Product Backlog they can finish by the end of the Sprint. They move those to a second list called the Sprint Backlog. It’s a helpful practice because a large list like the Product Backlog can be overwhelming, whereas a short one like the Sprint Backlog creates focus. They also set a goal for the Sprint and add it to the Sprint Backlog; an overall goal that can be used to better interpret the individual items.

After that, they start working. The Developers create the product, while the Scrum Master is there to help solve their problems if needed, facilitate their meetings, and make sure the framework is properly adhered to. The Product Owner is also available to help explain the items and issues if there are any doubts.

While they are working, they have 15-minute daily meetings called Daily Scrums, where they talk about what they’ve been doing, what they are going to do, and what problems they may have.

Sprints have a fixed duration and end when the time is over, even if some of the items in the Sprint Backlog are not finished. Those items will return to the Product Backlog and the team will proceed to the closing events of the Sprint. It’s essential to only proceed with items that are 100% complete, because that’s the only way we can have reliable feedback. For this reason, there’s a Definition of Done that describes (or implies) when an item is truly done. If something doesn’t satisfy all the conditions of the Definition of Done, it will be returned to the Product Backlog to be completed later.

The first closing event is a Sprint Review, where the team and the rest of stakeholders spend maximum 4 hours reviewing the latest features and collecting feedback. This is only one of the many opportunities for collecting feedback and not enough for true adaptation. The team has to provide the latest Increment of the working software to end users or at least end-user representatives to try out and generate feedback.

The last event is the Sprint Retrospective, where the team gets together and spends maximum 3 hours thinking about how they can improve their project in the next Sprint.