The Scrum Values – Focus

The next topics I want to discuss are the Scrum Values, these are Commitment, Focus, Openness, Respect and Courage. Or as I remember them Focus, Respect, Openness, Courage, and Commitment. I find the values some of the hardest parts of scrum. Not because I disagree with any of the values – I find them all admirable and praiseworthy but because I find them harder to measure. Its easy to see whether a team is running Daily Scrums, its less clear whether they’re displaying courage!

In his blog post on the Scrum.org website Steve Trapps talked did a fantastic job of articulating what these values look like when a team share them. For focus he said:

  1. Whilst working on a story I do not get distracted.
  2. If I am not enjoying the work in a story I still give it the attention it needs.
  3. When enjoying working on a story I will not over work a story just to prolong it.
  4. I do not procrastinate when working on a story.
  5. As soon as the story is ready to move into a new state, I will tell my colleagues and either hand it over or ensure that they know it is ready to pick up.

I think these are very valuable questions to ask yourself and your team to assess whether you are living the values which help support Scrum.

When Scrum Team Members focus on their work it helps the entire team achieve it’s Sprint Goal. This in turn moves progress towards the Product Goal and helps the Product Owner deliver real value to the customers. However, if team members are not focused, if they are distracted by endless emails or shiny opportunities then they often fail to deliver and the Scrum Team has to replan frequently.

Scrum Team members should value focus and avoid distractions.

It is everyone’s job as Scrum Team members to help reinforce focus wherever we can. To avoid distracting each other and to collaborate in a non-intrusive and distracting way. We should empower our developers to work autonomously and focus in a way which works best for them. For some people that means at home, for others that means in an office surrounded by people to collaborate with.

Keep focus in mind and always look for ways to encourage it both within yourself and within the team.

The Increment and Definition of Done

The last couple of posts I’ve written have been about the Product Backlog and Product Goal then the Sprint Backlog and Sprint Goal. Today I’m going to focus on the Increment and it’s Commitment the Definition of done. These are slightly different to the previous two Artefacts and Commitments, the Backlogs and Commitments described above show the current progress of work and the vision of what that work will look like when it’s delivered.

The Increment is the piece of work which is being delivered to the customer at the end of the Sprint. These should be as small as possible, however it’s possible that it may be the entire Sprint’s worth of development. The Increment is the next piece of the product which has been added to create more value. Scrum.org has a nice defintion of an increment.

An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable.

The Scrum Guide 2020

This is different to the previous to artefacts because it doesn’t describe the current state of what’s being worked on for the purposes of inspection, is is what’s being worked on.

Increments are added iterativly with each one meeting the Defintion of Done, this ensures that quality does not decrease during the Sprint. Photo by Startup Stock Photos on Pexels.com

However, as with previous artefacts it does come with a commitment. Where the Sprint Goal and Product Goal descibed the objectives we were working against the Definition of Done is a commitment to create transparency over what has been delivered.

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.

The Scrum Guide 2020

One of the biggest frustrations in modern software development is when something is “done” but exactly what that entails is a little hazy. One team may mean code complete, another may mean tested, another may mean deployed to a customer. The Definition of Done creates a shared agreement of what the team understands “Done” to mean. This prevents the awkward scenario where a stakeholder is expecting tested functionality but gets only code complete stories.

It also makes estimation easier because everyone has a clear understanding of what is expected.

The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment.

The Scrum Guide

If a team is working as part of a Nexus of Scrum Teams developing a single product, or if they’re part of an organisation providing components to another team then the Definition of Done should be shared to ensure that all teams share the same understanding of when something can be said to be Done.

If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum

The Scrum Guide 2020

Teams which do not have a clear defintion of done experience friction when engaging with stakeholders, uncertainty when it comes to estimates, and ambiguity when planning out work.

A good Definition of Done should include items like:

  • Acceptance Tests Pass
  • Non Functional Tests Passed
  • Documentation Created
  • Deployment Pipelines Created

It may also include “deployed to customer” if a team is following Continuous Deployment practices. However, for the purposes of Scrum we commit that our increments will only be “Potentially Shippable”.

One final point, the Definition of Done ensures that quality does not drop as functionality is added. The Scrum Guide states that quality does not decrease during the Sprint. The Definition of Done helps us verify that each and every increment is complete and quality is maintained before it is declared complete.

Hopefully this has been helpful, I think it may be time to look at the Scrum Values!