A developer recently explained to me that “agile means that we plan this sprint and know our backlog; whenever we get enough done on the backlog for it to be interesting, we release it, but we don’t ever plan more than the current sprint.” I didn’t choose to engage in an argument at the time; I just wanted to see his position. In my own work, I observed that the team was not achieving the definition of “done” on half of the stories in the two-week sprint. More interestingly, there was not even a common understanding of the goal of the sprint or the user value that would be achieved.
As we started having discussions about this, I realized that there were a few things missing:
- We had a very loose concept of a release plan, and the set of features (let’s call them epics) that would make up a useful release in the market.
- We had no estimates, and therefore no shared understanding, for the backlog. As we groomed the backlog to focus on only the interesting items for this release, the product owner team came to a realization that we didn’t have a shared understanding of the backlog items, and were uncovering this shared understanding during the sprint. I think I may have said “one of the cores of scrum is for the team to have a shared understanding of the requirement and the solution.”
Next week we’re going to do an estimating process, first for our next sprint which is just starting, and then for enough of a backlog for the next sprint. (We have a tradeshow coming up soon, so we have two sprints to deliver demonstrable value.) It’s not optimal timing within the sprint, but should get us to focus on our company objectives and have a shared understanding of what we can deliver.
Mike, at LeadingAgile, wrote a great post about estimating, titled “the real reason that we estimate.” I’d like to bring over a few paragraphs of his and then reflect a bit.
You see… estimating isn’t about estimating at all. Estimating is about creating a shared understanding of the requirements, and a shared understanding of the solution. When teams have problems estimating, its almost never an estimating problem, it’s a shared understanding problem. If you can get to the bottom of your shared understanding problem, you will fix your estimation problem.
The product owner needs to represent the problem well. The product owner team, a great concept of Mike’s, will work together to make appropriately bite-size stories for the backlog. The team will then estimate those. I’ll give my thoughts on product owners, product owner teams, who can create a story, and who is responsible for the backlog in the future.
Giving up estimating is basically giving up being able to give the business any idea of what they are going to get or when they are going to get it… even at a high level. My take is that we can’t give up estimating, we need to get better at estimating, but that means that we need to get better at creating shared understanding. It’s my opinion that creating shared understanding is the main reason we estimate. It’s not so much the number that matters… it’s the shared understanding that matters. If we are estimating without creating shared understanding, we are missing out on the value, and the estimates will always be poor.
One of the biggest things we need is some way to estimate size for epics (and stories as they get closer) and the business value of the epics. Then do release planning to determine roughly what will fit in, and refine as we go. But we’re doing this with some idea of capacity and time frame.
Speak Your Mind