![]() Reorder as necessary and that's all there is to it. What about business risks and technical dependencies? As they come up, wrap each risk or dependency in a separate feature you can rank against the features already on the bingo board. Then lay out all features by descending ROI. But it can't go more negative than minus one, so just add Plus One to all ROI numbers to fix that. You'll notice that this could go negative if duration is greater than value. There are a few choices for a formula for this, but I like ROI = ( Value squared – Duration ) / Duration squared. Each feature has two numbers, one for Duration and one for Value, so we can prioritise them by a simple ROI calculation. And now our business leaders make all the estimates while our design and technical leaders question them. But for business value this time, not duration. Play it again to get a second estimate on all Features in the release.And the new Momma Bear is kind of boring but you'd still get value from the system without it. The new Poppa Bear is an essential feature for a system - if it didn't do that, no one would use the system at all. A user wouldn't even notice if it wasn't there. The new Baby Bear represents something trivial - a bell or a whistle. These ones are features you already delivered that represent business value. So you just write these duration estimates down quick on the cards and take the features off the bingo board again because now we need to do it over, but this time for priorities. Now everyone's best thinking is in these estimates, they're much better than even your best architect could figure out by themselves. Have technical leaders make these estimates but have your business and design leaders question them until everyone agrees. Place each new feature on the board as you go - a table top works best - until all of them are ranked against the three bears and each other. Abd, one at a time, compare the features of your release plan with the three bears. Place your three bears at the right spots on this bingo layout.You get each bucket by adding the two before it – 1+2=3, 2+3=5, etc. This can be rough too if you don't have the data. Look at your old Gantt and Jira logs if you don't know what they actually cost. Not points, buckets of real resource x time. To do that you cost your three bears by some fixed time Unit – an FTE day or a squad week. And Mamma Bear – a medium sized feature just right in between the two. A Poppa Bear – a great big hairy feature that generated a great deal of OpEx. A Baby Bear – a little self-contained feature that was cheap and easy to deliver. Find "three bears" as a scale against which you're going compare the features of your release plan.You naturally break your product down into independently releasable features and then: Business Bingo for Feature Budgetsīusiness Bingo is a kind of breadth-first Planning Poker for product managers. Your teams can do it this way continuously and just-in-time. It's simple, and needs no release-delay trains or giant committee planning. There's an easy way to reconcile sprint and release plans that works for both delivery and business leaders. This doesn't mean we can't deliver agile and make it stick. Parse that any way you like, it's not good enough and it never was. Sprint planning blows release commitments out of the water without anyone noticing until the kaboom.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |