As in my last article, I aim to explain these changes in a very simple way, and although it’s not easy, the purpose is to help you with implementation of these changes within your teams and organizations.

1. Sprint Planned with a goal

Your Sprint Planning ceremony now has a new and helpful flavor, that is sure to please everyone.

Your Planning now requires you to share the value of the sprint, what can be done during it, and how it is going to be done. Let’s go through these three additions:

A. The Sprint Goal: How will this sprint contribute to Product Increment?

• The PO defines and shares with the team the increment they want to create.
• Each increment will be built in one or more sprints and the SM explains which part of it we are aiming to complete during the current Sprint.
• The team contributes to defining the Sprint Goal to achieve and explaining the Sprint’s value

B. What can be done this Sprint?

• The team selects items from the Product Backlog to include in the current Sprint, according to priorities given by PO. Clarification occurs if needed.
• Selection can be though. The team will base selection on past performance, velocity, and team capacity which will be clarified by SM

C. How will the chosen work get done?

• For each selected item, the team should create a one-day-off-work or fewer subtasks.
• This process is at the discretion of the Developers. They are accountable for this.
• This doesn’t necessarily need to be completed during Sprint Planning, but the team needs to work on this immediately after.
• Progress should be tracked following the completion of each of those subtasks.

2. Focused-on-progress Daily Status

The main purpose of the daily is still to track progress and report impediments so your SM can help with them. Though, gone are the usual three questions: “What did I do yesterday?”, “What am I doing today?”, and “Do I have blockers?” Teams are free to establish a new structure for the meeting, the outcome should be a plan for the day.

But, track the progress of what? Your Sprint Goal of course. For the team to have a clear view of what the Sprint Goal is, the SM should expose it during the previous planning meeting and the team should confirm they understand what their contribution is to accomplish it.

With the Sprint Goal in mind, the team should track progress and come up with a plan for the day. Considering that, I would dare to suggest two structure alternatives for your new daily status meetings. You will want to try them out so you can verify if they fit your team.

For both proposals, always avoid sharing information that is not valuable for the rest of the team. This information could include:

• Previous and current day meetings unrelated to the Sprint Goal 
• A deep dive into every single ticket. The team needs to know your progress, what you need to complete the ticket, and if you have impediments to doing so
• Issues that need to be discussed in detail. It's best to save these for after the meeting.

3. Artifacts with purpose

Artifacts represent work or value. They help keep the work backlog transparent and visible, and the team focused on what brings the most value first. Though there aren’t new ones, artifacts now represent a particular goal that demands a commitment. Now,  we can all measure progress as a team. It’s so beautiful when everything fits, isn't it?

• Product Goal -> commitment of Product Backlog, which is in constant review by PO.
• Sprint Goal  -> commitment for the Sprint Backlog once the team has selected it.
• Definition of Done -> commitment for the Increment, which the PO has defined.

4. General and Simpler Language

Scrum now operates with general and simpler language. With IT references removed (such as testing, designing, requirements, etc.), it is open to all kinds of teams and industries. Additionally, there is no Dev team anymore, just simply the Team.

Next steps

“Scrum is built upon by the collective intelligence of the people using it. Rather than provide people with detailed instructions, the rules of Scrum guide their relationships and interactions. Various processes, techniques, and methods can be employed within the framework.”

Scrum is an intuitive, empiric, and always evolving way of doing things in projects. It can’t just be unchanging and static, let alone so prescriptive that it is impossible to adapt it to different team’s conditions and necessities. 

After this exercise, I must confess I feel really excited about applying these changes in my own project and I confirm all the benefits it can bring. I don’t think it will be a single iteration, but a progressive and constructive experience among all my team members.