Estimation Archives

Waltzing with Bears is one of my favorite reads. It has become essential reading for anyone leading projects. It’s honest and pragmatic, providing evidence for the need and power of good risk management for project planning.

Rating

(Higher is better, 5 is neutral)

Would I recommend? 10 / 10
Did I learn anything? 9 / 10
Did I learn anything I can apply? 9 / 10
High Information density? 10 / 10
Would I re-read? 8/10

Buy Waltzing with Bears on Amazon

Waltzing with Bears Overview

Waltzing with Bears takes us through the journey of Managing Risk on Software Projects. It starts out analyzing what Risk really is and why it matters. Then it transitions into demonstrating what we can do about it, how to talk about it, tools we have, mitigation methods, and common pitfalls. It shows how analysis of risks & their probabilities can inform the probability curve of delivering a project

Ultimately Waltzing with Bears advocates for being open & honest about what on a project we can control, thinking about what risks we can mitigate, and how we can more realistically plan projects while including uncertainty.

Who should read Waltzing with Bears?

Every Project Manager, Product Manager, Head of Engineering, and Senior Engineer. It will shift how you think of projects and give you the tools to stop guessing about projects and start projecting realistic projects.

My main takeaways

Don’t ignore project risks. Risks make us more self aware and not count on ‘luck’ or ‘stars to align by chance’. We can eliminate a good portion of guess work.

We can use math to quantify risk asses its probability of impact on a project delivery dates or outright failure.

Deadlines dates are a bit of a myth. Instead a distribution confidences for completion is more realistic when Planning Projects and Road Maps.

Just because you wish / hope / believe that things will go perfectly, doesn’t mean they will.

If you did no diligence in checking for risks, and a project goes perfectly, you are just as guilty as someone who knew of risk and did nothing about them. See Ethics of Beliefs.

5 most common items that impact software project timelines: Scheduling Flaw (ill informed project timeline), Requirements Inflation (additional unplanned work), Turnover (staff leaving), Specification Breakdown (ignoring agreeing upon what/how key items are built), Under Performance (low/high throughput by team).

Riskology Worksheet is a great way simulate these risks impacts on a project.

If you liked this book, next I’d recommend

On team culture: Debugging Teams

Planning quarter roadmap and which projects to tackle is daunting.

It’s a lot to think about: What’s most important, What are quick wins, What work needs to be finished, Which stakeholders are most important.

Time to build matters

It’s easy to overlook the size of projects and how long they will take: Requirements are vague, Designs don’t exist, Dependencies are unknown — Everything is guess work.

Including the Team to Discover Scope

It’s tempting to hold tightly what projects are being dreamed of, holding them close until the start of the next quarter — revealing them at a kick off. Keeping the roadmap a secret is dangerous.

Two things this can cause:

Surprising the teams that will be building the projects, they have many questions.
The time and effort wasn’t decided by the team that will be building the projects, it was likely assumed.

Therefore it’s important to pull in the team to help build out the next Quarters roadmap. It should be clear they likely won’t be making decisions of what gets prioritized. Leveraging the teams to understand the systems that are in place, project managers can work with the team to understand guesstimate time range or amount of effort it might take to accomplish the possible projects project.

Better estimates of projects scopes that can inform prioritization.
Team is excited for & already understands projects that are in the pipeline

Temptations & Warnings planning quarter roadmap

It can be tempting for a team to dive into the technical implementation of a project. This is ok up to a point, but only to a hypothetical point. The goal is to create a rough range how long it might take.

Time ranges are important. There are always surprises, both good and bad that cause projects to go faster, but typically longer than expected.

When estimating, pick a unit for the time. Let’s say a project may take 2-3 weeks – but is that with 1 person? Or a full 3 person team working on it? It makes a huge difference! When pick units, Stay consistent with those units.

An extended form of hiking in which people carry double the amount of gear they need for half the distance they planned to go in twice the time it should take.
~Author unknown

It’s very tempting to take the low estimate. Don’t use the lower estimate! Projects always tend to run longer for miscellaneous reasons (bugs, scope creep, interruptions, pto, forgotten pieces, testing). It’s much more realistic to pick something in the middle or even the pessimistic estimation. I wrote about a related topic, Why We Estimate Stories which goes further into the cautions of under estimating.

Visualizing the Estimates

I’ve built a spreadsheet layout for looking at projects that have been picked for the roadmap and how they look on a time line.

Again it’s tempting to only look at the Optimistic estimate, and it might be best to delete the Optimistic row if temped by it.

On my teams it’s very important that the entire team focuses and works on only one project at a time (else you really have 2 teams not 1 and projects take longer, gasp!). We also estimated our projects in units of “number of weeks 2 devs working” for each project which makes it super convenient to map out.

I’ve made the Roadmap Planning Template available on Google Docs. Make a copy and give it a try.

Looking at this we can see a lot of great info. For example, we can see something interesting about Project B. It’s 4-7 weeks, the team isn’t very confident in it’s scope & needs. We either need to better define the scope, cut scope, or table it until we better understand it. It puts other smaller projects at risk. Perhaps Project D is high priority to complete in Q4. There are many great conversations we can now have.

Setting Good Commitments & Expectations

There were actually Projects A – J slotted for Q4. That’s 10 projects. Working with the team, even the optimistic projection puts us at the end of Q1, and pragmatically 1/2 into Q2!

If we hadn’t worked with the team to estimate the scope we would have been blind to our commitments we almost made in Q4. While we were excited with hope about all the things we would to accomplish in Q4 we would have been setting ourselves up for failure & disappointment & poor morale. Not only within our team, but also our external stakeholders.

Conclusion

Being pragmatic about commitments planning quarter roadmap is hard but hugely important in setting a team up for success. We are inherently optimistic creatures, we want to promise & hope to accomplish more than is realistically always possible.

Finding tools to help us be honest with ourselves makes us & our teams be honest & better people.

(cover photo credit: Jonathan Stassen / JStassen Photography)

Thoughts

Tag Archives: Estimation

Waltzing with Bears – Book Review