Author: Paul Ralton

Commitments and forecasts when using Scrum

A regular topic of conversation within my Scrum training courses revolves around commitments and forecasts when using the Scrum framework. Frequently we uncover significant and important misunderstandings about what Scrum Teams can commit to and what they cannot.

The most often talked about example refers to those Product Backlog Items which are taken into a sprint by the developers and which then seems to turn into a hard commitment such that if not all those Product Backlog Items are done then something is wrong and a possible belief that the Scrum Team has failed.

This article is an attempt to help debunk at least this one myth whilst using the Scrum framework to build complex products and an overall recap around commitments versus forecasts in general across some of the evolutions of the Scrum Guide over time.

Let’s be clear on what commitment actually means:

A quick online search gives these two definitions for ‘commitment’:

  • “The state or quality of being dedicated to a cause, activity”
  • “An engagement or obligation that restricts freedom of action”

These are actually quite different in meaning. The first relates to dedication. “I couldn’t fault the team for their commitment”. The second relates to a future state that we are promising to achieve, a guarantee, a promise.

Let’s now explore some of the key elements around commitments and forecasts from the Scrum Guide as it has evolved over time.

Scrum Guide 2010

  • The Team has committed to a Sprint Goal, and to these Product Backlog items

Within this first version of the Scrum Guide there is reference to the fact that there is a firm commitment that all items taken into a Sprint are to be done. If not all items selected are done by the end of the Sprint then maybe there has been some kind of issue worth exploring further. Have we therefore failed as a team since we did not achieve all that we promised?

A potentially interesting point around this is the fact that probably a lot of teams currently using Scrum today have never read this original 2010 version but yet still have a strong belief that all items selected must be done or else something has gone wrong. If this has not come about from reading this version then could it be due to the culture and behaviours already inherent within the wider organisation?


Scrum Guide 2011

Thankfully this use of commitment did not stay long and was updated in 2011.

  • …the Development Team forecasts the Product Backlog items it will deliver in the Sprint” 
  • …Development Team to forecast what it believes it can do in the upcoming Sprint” 
  • “…Commit is now forecast

Early on there was a realisation that when dealing with complexity and significant amounts of unknowns that it is simply not possible to perfectly plan all that is to be done even within the time-box of just one Sprint.
 

Scrum Guide 2016

The 2016 version introduced us to the Scrum Values and one of these is commitment.

In this regard it means (but not limited to) committing to being professional, committing to quality, committing to helping and supporting each other, committing to working on tough problems, committing to our goals. This touches on both meanings around commitment. Both on the dedication and effort perspective whilst also hooked into the promise of focussing on delivering future goals.
 

Scrum Guide 2020

The 3 commitments were then added in 2020.

Each of the core 3 artefacts now has a corresponding commitment which all help bring transparency to the artefact they are a commitment for – so for the Increment we have the Definition of Done, for the Product Backlog we have the Product Goal and for the Sprint Backlog we have the Sprint Goal.

Developers adhere to the Definition of Done…..that’s completely non-negotiable. That’s a firm commitment. A promise.

The Product Goal and Sprint Goal help Scrum Teams focus on current progress towards a future state which serves empiricism. A Scrum Team is committed to working on one Product Goal at a single point in time and either achieving or abandoning that Product Goal before then moving to the next one.

The Sprint Goal is created by the whole Scrum Team during Sprint Planning (note – the whole Scrum Team and not just the Product Owner). The developers are then committing themselves to creating at least one usable increment by the end of each Sprint that achieves that single Sprint Goal. This is their commitment. They are not committing to completing all the Product Backlog Items taken into a Sprint. As the Sprint progresses and as more is learnt about this work then so the Sprint Backlog is emergent. There has to be a level of flexibility that the Sprint Goal provides. The Scrum Guide makes this super clear:

  • …the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it” 

The Sprint Goal is the outcome we are after achieving….the Product Backlog Items selected to achieve that Sprint Goal forms the output. Scrum Teams should always look to maximise outcomes and minimise output. The Sprint Goal is their commitment…..the selected items are their forecast.


In summary…

Be clear what you commit to and what instead must be a forecast due to the inherent nature around complex product delivery.

Commit to goals. Commit to doing the best you can at all times. Commit to helping those around you. Commit to building products of the highest quality. Commit to the Definition of Done.

Remember that Product Backlog Items taken into a Sprint are very much a forecast and not a commitment. Forecast longer term plans with the expectation that these will continue to change and evolve as more insights emerge over time.

Ultimately understand and be professional around what you can and cannot make commitments against.

Want to learn more and talk further about commitments and forecasts, professional Scrum or indeed any element of the Scrum Framework? Check out our upcoming courses on our course schedule with b-agile. We offer both public and private courses to fit your needs.

Giving back: Considerations for a new Product Owner

Following on from my previous post (Considerations for a new Scrum Master) this blog aims to help those just starting out as a Product Owner.

Like my previous blog – the following items are in no particular order of preference.

The aim is to outline some of the key aspects that are probably worthwhile you considering as you get started on your Product Owner journey.  

  • Know your product
    • Make sure you know just what your product is, what problem(s) you are trying to solve and for whom
      • A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.” [The Scrum Guide 2020]
  • Generate a Business Model
    • Take time to explore something like the Business Model Canvas or the Lean Canvas in order to try and ensure that others around you begin to understand your product and its unique value propositions
  • Create and share your Product Vision
    • Your product vision should inspire those that are working towards achieving that long term goal
    • Keep it short, focussed and to the point – this will help others understand and remember it
    • Explore some of the many online templates available to help get you going
    • Pull in others to help you create your product vision – don’t feel that you have to do this alone
    • Aim to communicate and share your product vision at every opportunity that you have (as a minimum think about the core Scrum events)
  • Create a Product Goal
    • This should be an intermediate goal acting as a step towards your longer term product vision
    • Make sure it is measurable otherwise how will you ever truly know that you have achieved it
    • Ensure it is well understood by your Scrum Team(s) and wider organisation
    • Remember that the intent is to achieve or abandon a product goal before then moving onto the next one
  • Start to build your Product Backlog
    • Your active product goal should be in your product backlog but note that not everything in your product backlog has to directly relate to your product goal
    • Get others involved and consider exploring techniques like user story mapping to help get started
  • Identify key stakeholders
    • Consider running a brainstorming activity with everyone that you think would have an opinion in order to build a stakeholder map:
Stakeholder map
  • For the stakeholders that you have identified then consider placing them on a “2X2 power-interest grid” in order to know how best to involve them:
Power Interest Grid
  • Make use of your Scrum Master
    • Remember that Scrum Masters are there to help you as a Product Owner. Ask for their help and support around product backlog management and conversations/collaboration with stakeholders (particularly around facilitation). 
  • Make use of your Developers
    • Try to make sure that you don’t spend all day every day just gathering requirements, uploading them into some web-based tool, adding as much detail as you can and including things like acceptance criteria and then handing such items off to the developers. That’s clearly not a hugely valuable use of your time plus is not enabling true business agility. Get the rest of the Scrum Team involved to take more responsibility around product backlog management and remember that it will always be the shared understanding through conversation and collaboration that is most important.
  • Metrics, metrics, metrics
    • Consider which metrics make sense to measure in your context. Without metrics then how do you know that what you are doing is the right thing? How will you know it’s valuable? How will you know when to try something different?
    • Take a look at Evidence Based Management and begin to understand how the 4 key value areas relate to each other plus explore some of the candidate metrics that you might consider for your product (but remember this is not an exclusive list of all possible metrics).
  • Experiment, experiment, experiment
    • Consider what experiments you might run in order to better understand whether to pivot or persevere
    • Try to adopt the mindset and behaviours of an entrepreneur
  • Focus on shortening the feedback loop
    • Shorter feedback loops accelerate learning. Up until releasing then everything is simply a hypothesis. Remember therefore that you need to release in order to validate and potentially realise value.
  • Continue your Product Owner learning

I hope you find these thoughts useful as you begin on your Product Owner journey.

If you decide that you would like to come along to a Professional Scrum Product Owner class then feel free to reach out to me at paulralton@bagile.co.uk or take a look at our course schedule. We offer both public and private courses to fit your needs.

Also let me know your thoughts on the above….what’s missing….what else would you add for new Product Owners?

Giving back: Considerations for a new Scrum Master

I remember it well…as if it were yesterday. A certain day many years ago when I was told that I was to be a Scrum Master for a team within the organisation that I was working for at the time. Yikes!!!

I didn’t know just what to expect and I certainly didn’t really know what being a Scrum Master entailed and how might be a good way to proceed in those early days and weeks.

Maybe you find yourself in a similar situation….maybe you have more of a say than I did about embarking on the path to being a Scrum Master. Either way the intent of this article is to give back some of my personal thoughts and suggestions of things that might help you if you are starting on a similar journey. Things that I know now that I believe would have helped me back then. Do note that the following items are in no particular order but rather just my personal thoughts and ideas. 

  1. Read the Scrum Guide:
    Okay – I know I said these were in no particular order but I did feel that I had to begin with this one. I would openly hold my hand up at this point and state that it took me some time to realise that there was such a document that existed. Do take the time to read it….and then also keep coming back to read it again. Scrum is a lightweight framework and is purposefully incomplete. It doesn’t tell you exactly how to use Scrum in your context (remember that everyone’s context is different) but the Scrum Guide aims to inform you of the mandatory elements that make up  the core Scrum framework. 
     
  2. Introduce yourself to the Scrum Values:
    Needless to say that due to me being unaware of such a thing as the Scrum Guide then I clearly had no idea that there were 5 core Scrum Values which underpin the framework. These core values of FocusOpennessCommitmentCourage and Respect really help build trust, take us towards Professional Scrum and are the foundations needed for empiricism to thrive.
     
  3. Get to grips with empiricism:
    On the subject of empiricism then aim to understand early what it really means, why it’s so important and how the elements of Scrum support it.
     
  4. Know what is being inspected and adapted:
    There are 5 events in Scrum. Other than the Sprint itself which acts as a container for everything else then all the 4 other events are opportunities to inspect and adapt something. Make sure you are comfortable in what is being inspected and adapted for each event. If you are clear about this then there is a much better chance you can help coach and guide your team to achieving significantly better outcomes.
     
  5. Listen and observe your new team:
    Watch, listen, observe and understand where they are at right now. Respect their current approaches and working arrangements.
      
  6. Don’t be afraid to ask for help:
    Seek out other Scrum Masters within your company, reach out to your colleagues, check out the Scrum.org forums, attend meetups.
     
  7. Help establish a team charter:
    Does your new team have some kind of team charter or team working agreements? If not then maybe this is something you can work with them to start thinking about bringing transparency to how the team would like to work with each other.
     
  8. Look to build an empowered self-managing team:
    Think about what you can do as a Scrum Master to help foster the environment where the Scrum Team becomes more empowered and is able to self-manage around their work.
     
  9. Make use of the available resources on Scrum.org:
    Check out the Scrum Master Learning Path and see what is available. There is a rich array of amazing blogs, videos, webcasts, whitepapers and a whole lot more.
     
  10. Begin to explore Liberating Structures:
    As a Scrum Master then over time there will be an expectation on that you are an awesome facilitator. Note that this is not just limited to the core Scrum events which you can facilitate (if needed) but also to other meetings outside Scrum which might require effective facilitation – so for example helping your Product Owner with some challenging conversations with key stakeholders. Liberating Structures are a set of microstructures that are designed to help collaboration and conversation whilst ensuring that everyone’s voice is heard.
     
  11. Check out the fantastic YouTube series of Your Daily Scrum videos:
    Created by fellow Professional Scrum Trainers Ryan Ripley and Todd Miller as part of Agile For Humans. There are a lot of great questions being answered so take your pick.
     
  12. Think about formal training:
    Enrol for a Professional Scrum Master course with Scrum.org. The concept of Professional Scrum is extremely important (see above) and as a Scrum Master you should have an excellent appreciation and understanding of just what that means and your role in supporting it.
     
  13. Move towards Flow Metrics:
    Anyone that knows me well would be hugely disappointed if I hadn’t included some kind of reference to Flow Metrics. I would definitely be planting this seed in the minds of all Scrum Masters both new and experienced. Utilising Flow Metrics as part of your Scrum implementation can be hugely powerful and beneficial. 

Should you find yourself in a similar situation to where I found myself all those years ago then I hope the above gives you something to consider and helps you establish some kind of path forwards.

I am clearly hugely biased but being a Scrum Master is a fantastic opportunity where quite often no two days can feel the same and you frequently will need to take different stances (or combinations of stances) depending on the situation in in in which you find yourself. You should expect to be continually learning and helping others continually improve.

If you do decide that you would like to come along to a Professional Scrum Master class then feel free to reach out to me at paulralton@bagile.co.uk or take a look at our course schedule. We offer both public and private courses to fit your needs.

Let me know your thoughts on the above…..what’s missing…..what else would you add for new Scrum Masters?

Over time I plan to expand on some of the above items so watch this space!