Two basic types of release plans that are widely used are scope-boxed release plans and time-boxed release plans.
“In a scope-boxed plan the work that the team will do is defined in advance, but the release date (time) is uncertain. In a time-boxed plan the time and release date is defined in advance, but the specific work that people will do is uncertain and is being elaborated with time.
“Time-boxed plans are the most preferred way of release planning. This will constrain the amount of work and people will automatically start doing the prioritization which is the fundamental concept of Agile.”
PMI Agile Certified Practitioner; Chapter 5: Planning, Monitoring, and Adapting
The length of a single task is notoriously difficult to estimate. But without an insertion ritual estimates don’t even matter because no one consults them. It’s a free-for-all.
Over a year ago I was part of a committee trying to improve our “on time performance.” Our conversation took me back to the heady days of my internship at Novell. Funnily enough, my old manager from that job was there. He had once given the same well rehearsed speech that another senior manager was giving:
The Golden Project Planning Triangle of Gold
Let’s review the storied planning triangle that every technical person ought to be familiar with. When you plan a project there are three major components: scope, schedule, and resources.
Resources includes people. We know they are people. Please look beyond the fact that they are called resources. We love you all as the individual and wondrous snowflakes you are.
Continue reading Your Plan Needs an Insertion Ritual
The snow-shoe hike to Donut Falls was supposed to be the capstone to last night’s overnight camp. So, why do I feel good about giving up on the hike this morning?
Just yesterday I posted about sticking to your plan. Why am I satisfied now with an outcome that doesn’t resemble the plan?
Continue reading Why Am I Happy About Giving Up
I’m on a scrum team. In sprint retrospective many members of the team share a concern that the team isn’t moving as fast as it could. Things seem to have slowed down. We brain storm as a team. We look closer at the coming sprint’s plan. The Product Owner considers the team’s concerns and throws some stories overboard. One of them looks like an Easy Story. The product owner is getting business pressure to ship it. To give the team time to address concerns they raised in retro he throws it overboard.
“But wait,” one optimistic developer says. “That’s an easy story. We can still do that.”
“I’m not going to tell you guys everything to work on. Use your judgment. If it only takes a quick conversation then I’d love to have it. But I’m not committing you to it.”
All my dreams have come true. A Product Owner that gives clear direction, latitude, and cares about craftsmanship.
The next day. Stand-up. Will the Product Owner’s generosity be rewarded?
Continue reading Stooping for Pennies Loses the Crown