Скачать с ютуб Agile Estimating / Agile Estimation - Why Bother? в хорошем качестве

Agile Estimating / Agile Estimation - Why Bother?

Agile Estimating: it's a subject I've been avoiding. As Agile topics go, it's emotive. It's all too easy to ruffle feathers. = = = = = = = = = = = = New for 2024: my best-ever training: "How Your Agile Teams Can Achieve Predictability and Productivity WITHOUT Burnout" → https://www.developmentthatpays.com/w... = = = = = = = = = = = = Agile Estimating: it's a subject I've been avoiding. As Agile topics go, it's emotive. It's all too easy to ruffle feathers. It's also a broad topic. Where to start? We'll start by looking at what happens if we: 1. Sort the Product Backlog in order of descending VALUE 2. Do no estimating whatsover 3. Set to work Will it all end in tears? Music: 260809 Funky Nurykabe: ccmixter.org/files/jlbrock44/29186 ------------------- 55. Agile Estimating / Agile Estimation - Why Bother? #DevelopmentThatPays Agile Estimating. It's a subject I've been avoiding. As Agile topics go, it's emotive. It's all too easy to ruffle feathers. It's also a broad topic. Where to start What about right at the beginning with a pretty fundamental question: "Agile estimating: Why bother " Why bother ---- A couple of weeks ago, Andre Luis left this comment on a video: 'Can you do an episode on estimating tasks ' Andre, thank you very much for the suggestion. It's an interesting - and potentially controversial - area. Let's start the journey by asking the question 'Why ' Why do we even need to estimate Context --- To get to where we're going, a bit of context will be helpful: In a couple of previous videos, I've described Software Development as a process where... the Product Owner decides what to build, the Development Team gets on and builds it, and the Customer uses, experiences, benefits from it some way In Agile software development, the "value" is delivered to the customer, not in one big lump, but in a series of increments. Feedback from the Customer - together with input from other sources - is used by the Product Owner to create and maintain a prioritised list of 'stuff to do': the Product Backlog. It's the Product Backlog that we're interested in, so let's remove some of the clutter. And move things around a bit. I'm also going to re-draw the Product Backlog. And spread the items out a bit. And squish them a bit All kinds of things can be listed in a product backlog: features, bugs, infrastructure work, spikes, etc. For our purposes here today, I.m going to assume that these four items are all Features: They are all things that the customer will - in due course - see or experience. So much for the CONTENT of the Product Backlog. What about the ORDER of the product backlog Well, that's ANOTHER subject that could fill a book, so we'll keep things simple and consider just one factor: VALUE The VALUE that the particular feature will provide to customer. To recap: These four Backlog items happen to be FEATURES And they have been prioritised in descending order of VALUE. Let's indicate the relative VALUE with a bit of re-sizing: No. 1 has the most value, No. 2 is next, and so on. A bit of a colour would be nice. Too subtle. That's better. Development Time! ------- It's now time for the Development Team to set to work! The team is going to start - as you'd expect - with the item at the top of the Product Backlog. Once that's done, the team takes another item from the top of the Product Backlog. And so on. Before we know it, a whole pile of value has been delivered to the customer. Excellent. But here's the thing: It was done without ESTIMATING a damn thing. This episode was supposed to be about estimating, so it's a little awkward. Somewhere along the way, I made one assumption too many. I'll reveal all at the beginning of the next episode.    • Agile Estimating / Agile Estimation -...      • Agile Estimation