You guess. And you’ll be wrong. And that’s okay.

Capacity is just a mechanism to help the team determine a Sprint Goal they can deliver; they’ll then inspect and adapt daily to meet that goal. But it’s okay to make a prediction (ie a Goal), get it wrong, then inspect and adapt.

I’d suggest it’s more important to slice the work down into stuff that 1-2 people can do in 1-2 days, and make sure the team understands the work. A bunch of other stuff won’t go well in the first Sprint too.

So – you’ll have a lot to unpack in the retrospective…

Yes, if you don’t allow time for reflection and improvement, then there will not be any.
So build that time into what you do. Have communities of practice that meet regularly.
Build in slack time. Have occasional hackathon events.

SAFe builds this in as part of the “Innovation and Planning” iteration (Sprint), which is usually one two-week Sprint every quarter devoted to this kind of thing.

If you don’t do this, then people will eventually seek growth outside of your organisation. You’ll end up in a permanent recruitment and onboarding cycle.

I’d suggest watching Amy Edmondson’s TedX talk on YouTube, referencing Google’s research on their Re:Work blog and then discussing the implications.

Other things that might be useful are the “Conscious Leadership Groups” YouTube videos on “location location location” and “the drama triangle.”

Keep it simple, and use that as a way to move towards a working agreement around behaviours.

Even better if you integrate this into a learning programme around effective communication, conflict resolution and negotiation skills.

Well, the main thing in an agile context is that the people who do the work are the only people who should be involved in estimating it. What I’d add to that is that
– guesses are not estimates
– estimates are not forecasts
– forecasts are not promises
The second key thing is just how you go about creating the work for the product backlog. My counsel would be to use the User Story Mapping approach that Jeff Patton describes in his book, on his website, and so on. In this
– you co-create with the customer what they want
– you split it into a “spine” (look up “walking skeleton”) and subsequent releases
– you size the work as a group, with the customer involved
The key thing about that sizing is that you uncover different perspectives and unknowns; these drive “research spikes” that help you refine the work, while negotiating with the customer. In that way the process is co-creation, rather than a transactional approach.
The second key thing is to avoid adding too much detail too soon. You need to do that for the most important thing (the “spine”) but not things that are further off. By the time you get to those, you and the customer will know more. Maybe they will change?
I tend to get the team to estimate those things in Sprints, using Fibonacci and asking them for a range they are 85% confident in. We’ll also surface a lot of unknowns there, and identify potential research spikes or things the customer needs to think about before we get there.
So now you have :
– micro-scale estimates in points for the first thing you need
– meso-scale estimates in a range of sprints for the next priority items
You can turn that into a forecast in a few ways; summing the midpoints of the ranges is the worst. Including the range as a variable is better(*). Monte Carlo modelling is better still.
if you ignore the worst way (just summing the midpoints) that gets you to a range of dates, in a cone of uncertainty. But remember those assumptions? They go along with the forecast.
Then I reforecast often; as we complete a big item we’ll user story map in detail the next one.
As we uncover new information, we’ll revisit the meso-scale forecasts.
As we discover more about the team throughput, we’ll adapt again.
Mostly that gets us to a point where we can collaborate on decision making with customer in a useful way.
(* this requires a bit of stats knowledge, but what I do is
– make a table of the items in excel
– put in the low and high estimate ranges in columns
– calculate the midpoint in a new column
– calculate the error bar (midpoint – low estimate)
– assume the error bar approximates the standard deviation
(remember that 85% confidence limit)
– create a column with the standard error (standard deviation squared)
– create a column that is the cumulative sum of the midpoints (M)
– create a column that is the cumulative sum of the standard errors
– create a column that is the square root of that cumulative sum of standard errors (S)
– create a column that is M-S; call this 16% chance of delivering, the early forecast in Sprints
– create a column that is M+S; call this 84% chance of delivering, the late forecast in Sprints
– convert Sprints to Dates with a look-up table.
If you want 5% – 95% confidence, then use M-2S and M+2S instead
Now that’s a pretty crude model, but it is capturing the team’s uncertainty in a realistic way.
As you uncover more, so you can refine the model.
Where there’s too much uncertainty, you know where to do research spikes to clarify.