Scrum Development Cycle

1.0 Background

pivot team uses Scrum as a framework to deal with and solve complex problems while building products in a creative and efficient way, with the greatest value possible.

Transparency The process used by pivot team, whose activities and expectations are visible to all those interested in the team’s results. Nothing is swept under the carpet.

Inspection Work is inspected frequently. The pivot team asks ourselves whether it is progressing towards the goals and business results. It should also ask ourselves how to perfect its working method, the team atmosphere, and the quality of the product being delivered. Using Scrum is to constantly question: how can we improve?

Adaptation If the inspection determines that we’re not progressing to our goals, it’s time to adapt. This adaptation can be motivated by different factors: changes in the market, competition, client needs, business needs, invalidated hypotheses, among many others.

2.0 Scrum Development Cycle

The illustration below shows the Scrum Development Cycle. It contains the roles described above, events, artifacts, and some good practices we use to facilitate the life of the Scrum Team.

2.1 Sprint

The main event of Scrum, when all the work is carried out. It begins when we start the Sprint Planning and ends after the Retrospective. It is a time-boxed event. During the Sprint, items on the Sprint Backlog are built and turned into potentially deliverable product increments. The Sprint Duration is fixed and it’s two weeks and no breaks between sprints for pivot team. This period DOESN’T keep varying.

2.2 Sprint Planning

The Sprint Planning Meeting is Time boxed to 2 Hours. This is the moment when the Product Owner discusses with the Development Team which backlog items should be developed in the next cycle to build the product.

One of the first things the Scrum Team must do in planning is to define the Sprint Goal.

Once the Sprint Goal has been defined, the Development Team, together with the Product Owner, defines which items will be built in the Sprint. The Sprint Backlog is the series of Product Backlog items selected for the Sprint, plus the technical tasks. The Development Team can further detail the backlog item and in doing so will “break it up” into the technical tasks necessary for turning it into a product increment.

As soon as the Scrum Team defines the Sprint Backlog, the work begins turning the selected items into product increments.

2.3 Daily Meeting/Daily Scrum

The Daily Scrum occurs every day at the same time of day at 9:15 am for pivot team. During this period, the Development Team meets daily at the Task Board for the Daily Meeting. This meeting is carried out by the Development Team for the Development Team. This event should last 15 minutes at the most and the goal is to define what the Development Team will do that day to progress towards the Sprint Goal. To support this purpose, the Scrum Guide suggests three questions, but they’re not obligatory:

What did I do yesterday which helped the Development Team achieve the Sprint goal?
What will I do today to help the Development Team achieve the Sprint goal?
Can I see any obstacle which hinders me or the Development Team to achieve the Sprint goal?

2.4 Task Board

pivot team is using Jira board as a collaboration tool for the Scrum Team’s transparency. It contains all the work the team must do during the Sprint, including activities not related to product development (participation in committees, support for other teams, maintenance of other products, meetings, etc.)

2.5 Sprint Review

Every Sprint includes Sprint Review for stakeholder feedback on the product. At the end of the Sprint, the product increment is presented to consumers, users, clients, management, and other stakeholders. The whole Scrum Team takes part. The primary goal of this event is to get feedback about the product. The feedback given by guests can become new items on the Product Backlog. They may be highly strategic and go to the top of the backlog. Otherwise, they can go in the middle or just at the end. There is also the possibility of discarding feedback if it’s not relevant. The important thing about this event is that the consumer uses the product. It isn’t a meeting for presenting slides or increments which don’t meet the demands of Definition of Ready. In this meeting, information can be presented about the project’s progress, but the focus will always be on feedback about the product or service.

2.6 Sprint Retrospective

Every Sprint includes Sprint Retrospective for the team to inspect and adapt. This is the moment for continuous improvement. The whole Scrum Team takes part and the goal is to improve the whole team’s way of working. It is a safe environment in which the Scrum Team discusses mistakes and weak points. So there should be no people from outside the Scrum Team unless the whole team agrees to invite someone.

This isn’t an official Scrum event, but it’s good practice. The refinement can be done at any time and we can organize meetings for it.

The goal is to keep the Product Backlog updated and prioritized with input from new ideas, previous results, clients, management, market changes, changes to competition, innovations, etc.

It’s also good that the Development Team takes part in the refinement to estimate the effort or discuss the technical complexity of the priority items. However, this shouldn’t consume more than 10% of the Development Team’s capacity during the Sprint.

If the refinement hasn’t been done before, it’ll take place during the Sprint Planning. In this case, it’ll be a very long meeting. Ideally, the Product Backlog will have been updated and valued before the planning event, if possible with the estimated effort.

2.7.1 Product Backlog

The main input artifact is the Product Backlog. This is the series of all client and business needs which the product has to resolve. The Product Owner keeps valuing and prioritizing this backlog. Items don’t have the same level of detail. Those on the top of the backlog (greater priority) contain more information about what will be done, the purpose, and who they’ll be delivered to. The greater the priority, the more detail.

2.7.2 Definition of Ready

Some teams like to use a minimum definition to guarantee that the item has been refined and can be discussed in the Sprint Planning. The Definition of Ready is also not officially part of Scrum but does help the team lose less time and be more focused during the planning discussions. Examples might be:

The item must be written in User Story format;
The acceptance criteria are defined;
The metrics for measuring the impact of the item have been selected;
The business value of the item has been defined;
The item’s consumers were invited to the Sprint Review;
The effort to build the item has been estimated.

Table of Contents