I know the common phrase is “content is king”, but as far as Agile is concerned it’s context that is key.
When a team starts a new initiative, it’s important that they understand who it is for, why it is important, what value is it expected to provide, what problem(s) will it solve, etc. Without this context, the team can’t be expected to know if they are building the right thing — all they can do is follow the Product Owner’s direction.
As much as we look to the PO to represent the stakeholders’ needs, the development team need to understand the bigger picture: how does this feature fit into the product? With a wider context, the team can think about a general technical direction, bearing in mind things will change and the project might end before finishing the whole thing (hopefully because the customers are happy rather than running out of time/money).
The team can also identify risks, dependencies and unknowns — not all of them, of course, because there will always be discoveries as they dig deeper. They can create spikes, run experiments, build a proof of concept, and/or change the prioritisation of the backlog in order to reduce those concerns. This is a big difference from my experience of waterfall projects where the project manager would fill in the risk assessment sheet and file it away.
Tackling the high-risk issues early can improve the confidence in the rest of the backlog, or (in at least one project I can recall) result in the project being canned because it would be too expensive to resolve a showstopper… and this is a good thing! It’s far better than we identified the risk and investigated our options, so that the PO could make an informed decision whether to proceed. The alternative is to plough time and effort into the project and only think about the problem when we couldn’t ignore it any longer — that would have been a huge waste.
So how do we help the teams gain the context they need? I find Jeff Patton’s Story Mapping incredibly useful — the template I use is slightly different to Jeff’s because I really want the initial conversation to focus on the who and why pieces. The “Frame the problem” section is important in Jeff’s approach too, but I find the addition of specific sections in the template reminds the team (and the facilitator!) that we need to spend time really…