Skip to content

Peak inside my head

Agile risk management

Responding to change over following a plan. That is one of the values of the Agile Manifesto. The value often frames "Agile" as chaotic: No structure and no planning. At least, that is one observation I have had the last four years acting as a scrum master.

My family and I have returned after a great week of autumn vacation on the island named Sejerø. The home trip included not one, but two trips with ferries. The planned departure was on the day of the worst storm surge in Denmark in more than 100 years. How did we respond to the many news reports about the upcoming bad weather?

We started sketching a couple of contingency plans. We had a pretty good idea of what we could do on any island (Sejerø, Zealand, or Funen) that were in between us and the mainland. We didn't need to sketch it out when planning the vacation. And we didn't end up with detailed contingency plans. The planning was of high importance to us, but the plan was not.

In the end, we got lucky with our initial plan. The storm didn't come until later that day. Both captains were confident that it was safe to travel — and it certainly felt safe as well.

I'm happy we spent some time having a conversation about the contingency plans. I wouldn't want to be stranded somewhere in bad weather with my kids without a plan B — if it can be avoided.

Risk management comes in many flavors. It isn't unique to agile. Risk management is a way to plan responses to changes and that is valued in agile.

Sejerø is a beautiful island. It wasn't the first time we went there, and it won't be the last time. The picture was captured by my wife and shows the lighthouse of Sejerø.

Sejerø Lighthouse

This was originally shared as a LinkedIn post on Sat, 21 Oct 2023 18:17:39 UTC.

Agile estimating

I love estimating in hours! Even minutes. I do it all the time.

However, I strive to only do it in my private life. For example, I estimate the time, it would take me to cook supper so that my family gets food on time.

In my professional life, I strive to estimate the effort, complexity, the amount of work required, and the level of uncertainty. They are all summarized in a single number called a story point (SP).

That's at least how I see a story point. I've noticed some buzz around the SAFe 6 definition of a story point. According to SAFe 6, one story point is equal to one ideal workday for one person minus 20% general overhead1. To me, this seems like a potential issue with relying too heavily on time-based estimates.

Going back to cooking. The time I would estimate cooking supper is probably higher than my wife's estimate. And that's one example of where time estimates fall short. They don't work in cross-functional teams. Some people are faster and with a flair for higher levels of built-in quality for a specific task than others.

A reference recipe with known effort, complexity, amount of work required, and level of uncertainty can help people agree on a story point for a recipe. Comparing this reference recipe with a new recipe provides a relative estimate. The history of cooking similar recipes can give an upper and lower bound on the time estimate for the team to complete the task in its entirety.

Agile estimation

This was originally shared as a LinkedIn post on Wed, 22 Mar 2023 06:15:00 UTC.

  1. This has since been updated in the SAFe framework. This has now been moved to a section named "Starting Baseline for Estimation" ↩