What if you can plan for a few weeks or even a month-plus at a time? You don’t need the extremely short feedback cycles (hours to a day) because you’re not doing high innovation. You don’t need to change what the team does every few days.
You can estimate and commit to maybe a month’s work at a time. On the other hand, you need to change your work more often than a two or three month period. That much estimation seems like a waste. And, the commitment part? You laugh at that. You might like to commit, but you need to change.
That circumstance is this part of this series: moderate innovation work, the center part of the image.
Moderate Need for Product Innovation and Change
When the team can plan—and not need to change its plans—for a couple of weeks at a time, the product has a moderate need for innovation and change.
In this case, maybe the team can use short iterations of one week or two. And, if management doesn’t need to change more frequently than the iteration duration, the team might spend time estimating in the small for the stories in the iteration backlog.
If the team is likely to change what they do for the next iteration, it does not make sense to estimate an entire feature set. Many feature sets take longer than one iteration to complete.
Management doesn’t need to see the estimates because the estimates are not for the entire feature set. Management needs to see feature progress for each feature set. Then, the people who manage the product strategy, the product manager/product value team change what the team does next.
For seeing feature progress, I recommend the product backlog burnup chart and feature charts. See Velocity is Not Acceleration or Create Your Successful Agile Project for more details. Notice that what a team does in an teration is not that interesting. It’s how the product grows and how the team(s) finish which parts of the feature set that is interesting.
The more often the teams finish “enough” stories in a given feature set, the more often the team can replan.
Too Much Estimation is Waste
If management and the product manager/product value team aren’t synchronized, some people (often the managers) will ask the team for estimation. That doesn’t make sense and shows a lack of collaboration among all the manager-types. The team shouldn’t have to pay for that, but too often, they do.
Let me emphasize again why estimation isn’t often worth the time on moderate innovation work: The team will change what they do and that causes estimation changes. The PO (or product value team) realizes they don’t need “all” of the feature set. At some point, enough is enough. When teams estimate “all” the stories and they don’t implement all of them, the estimation is waste. See Frequent Releasing Can Lead to Short and Frequent Planning for more details.
Aside: What if the team does a few stories in this feature set and then a few stories over there, and returns to the first feature set? The underlying code has changed. If I ran that project (it’s even worse in a program), I’d want a new estimate. The old estimate is no longer valid because of the changes.
The team needs feedback from the product owner as soon as they finish a story. My opinion: the team still needs one-day stories (or shorter). Or, the team mobs to complete a story each day. The fast feedback cycles for the team helps the PO see what to rank next and what might need to change for the product.
I’m assuming the team will refactor/reanalyze/redesign as they proceed. I am not assuming the team intentionally short-changes the code and tests and creates cruft. That’s why the stories need to very small.
What if the team needs to explore/wayfind/spike for a few days to a week first, to understand the technical implications of a given approach for that feature set? The team does that. In moderate innovation projects, the team doesn’t have time for one person to amass knowledge. The entire team needs to gain the knowledge from the exploration.
With moderate innovation, managers make these tradeoffs:
- Because they will see the product evolve and they can change the order of stories and feature sets, they don’t need a lot of estimation
- Because the team will learn as they proceed, the team reduces risks so the managers don’t need estimation for the short term.
Next up is the low innovation product circumstance.
The series:
Balance Innovation, Commitment, & Feedback Loops: Part 1: High Innovation Products
Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Balance Innovation, Commitment, & Feedback Loops: Part 2: Moderate Innovation Products Opinions expressed by Java Code Geeks contributors are their own. |
