January 22, 2020

Forecasting a Committed Goal

Overview


Whilst in a meeting I heard a colleague explaining to another colleague

"...that within Scrum a Development Team commits to deliver what they bring into the Sprint Backlog".

Listening to the conversation a little longer the same belief was expressed again. At this point I had to interject explaining that the Scrum Team do commit, but they commit to the Sprint Goal and that the Sprint Backlog  contained a forecast of work for the sprint. 
    
The question then became what is the difference between a commitment and a forecast?

 "It sounds like that Scrum Team is not working as hard if they just forecast something"

The person wanted them to commit to deliver.  I've had this numerous times, when a manager has expressed a desire for the team to commit as they just seem to be doing nothing or always talking to each other and not coding. (This is another blog post in its own right)

The act of commitment is important and one that shouldn't be taken lightly. When we commit we should do almost anything to achieve it and should feel disappointed if we don't.   

What does the Scrum Guide Say....

In Sprint Planning....

 the Development Team works to forecast the functionality that will be developed during the Sprint.

Lets have a look at that - They are not actually forecasting the work that they'll do in the sprint. They are forecasting the functionality that will be developed.

I think that this is an important distinction -  "the functionality, not the work to be undertaken".  I believe that people often miss this distinction.

So does this mean that teams are less committed to delivery?

Forecast vs Commit

Forecast 
    predict or estimate (a future event or trend). 

Commit 
    pledge or bind (a person or an organisation) to a certain course or policy.

A predict verses a pledgePrediction over Certainty 

We work in an complex world;  there are more unknowns than knowns. We handle this complexity by being transparent with what we are doing, inspecting on a regular basis and adapting our approach based on feedback. Can it be wise to commit to something when you don't have all the information and are unsure how things may turn out? - I don't think so.

In September 2020 I intend to run in the world's largest half marathon - The Great North Run. This will be about my sixth time I've done it and in the past my finish times have been 2:00:00.59 (for the first one - gutted) to 2:20.00(slowest, the second time - when I didn't give it the respect it deserved based on the effort the previous year) and 1:54:29 (my fastest yet). 

My hope-vision for the run is that I'll complete it in less than 2 hours. I will be happy if the clock says 1:59:59 and less happy if it says 2:00:00. (seriously I will - its that important to me)  

My question to you is based on the evidence of previous times for the same event -

Can I commit to completing the half marathon and will it be less than 2 hours?

I've done this before so I should be able to commit to do so - It should be easy for me to commit to do based on previous experiences. 

Unfortunately, I can't as there is too much uncertain between now and crossing the finishing line in September. What happens if I don't do enough training, what happens if I get injured, what happens if it pours down with rain on the day of the run, what happens if I get stuck behind a group of people running slower than me?

Can I forecast that I can complete the half marathon and will it be less than 2 hours? Well the optimistic in says Yes!!, the pessimistic in me says "Mmmm it possible, but I'm not confident.". Can I forecast the things that will need to be happen in order for me to run under 2 hours? - Most certainly. 

Between now (January) and the date of the run (September) I will be setting myself goals to aim for over the next 9 months. This should enable me to adapt my forecast based on what happens if or when I hit the goals. 

Can I commit to those goals? - Yes, if I think they are sensible and realistic. 

Possible Goals 

  •   Reduce my weight by a considerable, but safe amount. (less weight, means less bulk to carry around the 13 miles)
  •   Increase the level of my exercising - more than two session a week for more than 30 minutes each session. 
  •   Do one long run at least once a month. (Long run is more than I have previously done so far)   
  •   Start running at the pace I need in order to go under 2 hours - (a minimum 5.41 per km or 9.09 per mile)
  •   Run the at the pace required for a substantial distance.

    
These goals don't guarantee that I'll hit that sub 2 hour mark, but based on the position I am now it is a good start to reach my vision. 
    
SO lets take that first Goal, How can I reduce my weight considerably, but in a safe amount?

  • I can do a calorie control diet.
  • I can stop eating in-between meals.
  • I can stop drinking beer.
  • I can exercise more, potentially burning more calories than I'm taking in.
  • I could do a crash diet & exercise every day

When setting goals you have to set realistic and sensible ones; ones that can be achieved and ones that won't leave you in a worst future state for future.  Apart from running at a certain pace, the majority goals are not too prescriptive. Success is defined by the outcome not the output. If the goal becomes unachievable then we need to rethink our strategy and approach.   

Looking at second goal, lets approach this if we committed to the backlog (which we don't....but)  

Goal -  "Increase the level of my exercising", what if I injured my Achilles tendon and I can't go out running. If I filled my schedule, i.e. my sprint backlog, with run after run for more than 30 minutes, and I had committed to the backlog I would be making my injury worse and damaging any chance of successful outcome.

As Scrum Team commit to the Sprint Goal, I could easily swap out the running items and go swimming instead and still meet my goal. 

So, because we don't know what is going to happen over a period of time we can't commit to the backlog, but we can forecast what we believe we can deliver. 

Take Away 

Scum Teams commit to the Sprint Goal - Not the Sprint Backlog.

Scrum Teams forecast the functionality that they can deliver within the Sprint, not the work.