Story Points - What's the Point?
Vložit
- čas přidán 27. 07. 2024
- Story Points are a cornerstone of Agile Estimating. But why do we even need them?
= = = = = = = = = = = =
New for 2024: my best-ever training:
"How Your Agile Teams Can Achieve Predictability and Productivity WITHOUT Burnout"
→ www.developmentthatpays.com/w...
= = = = = = = = = = = =
Download your FREE CHEAT SHEET: www.developmentthatpays.com/c...
CREDITS
- Pointing hand by Denis Sazhin from the Noun Project
-------------------
121. Story Points - What's the Point?
#DevelopmentThatPays
This is a map of the UK. Notice anything strange about it Not really a fair question. I grew up colouring in pictures of this map at school, … For those of you that didn’t This is …. A more conventional view of the UK/ The reason this version of the map is distorted, is that it’s not a map of distances…. it’s a map of… time. The map represents travel time. More specifically travel time from London. Every point on this arc is the same travel time from London. (By the way this kind of map is called an Isochrone - in case you want to Google for a map of your own country or region.) The strentching that we see in Scotland … the easyt…. And the southwest (check this) is a reflection that the transport system in these areas… is less well developed. Which, I have to add is no bad thing. Would you build a motorway through this For planning a trip, this map is excellent: I get a true indication of how long it will get somewhere. With no nasty surprises - Like the one I got the first time that I drove to the Highlands of Scotland. But there are a couple of drawbacks to this map that you’ve probably already spotted. This version represents travel time from - and, I suppose, to - London. Great for me, because I live in London. But if I lived anywhere else… I’d need a different version. There’s potentially an infinite versions of this map, each with a different starting point. That’s one problem. Another is that whoever put together this map made some assumptions about the mode of transport. Is this a map of travel times for car travel… or via public transport The shape of the map will be different in each case. It would be different again for walking… and for cycling. So it turns out that this style of map isn’t as useful as it might look at first sight. The conventional map turns out to be more useful… even though it doesn’t give me the number I want directly. I want travel time, But I’m very comfortable with “deriving” time from distance. And I bet you are too. We’re very used to starting with distance… And then “transmuting” it into time. If I ask you how long it takes to drive from Paris to Brussels… You may not have the first idea. If I tell you they are 314 km apart - that’s just short of 200 miles … You can take a stab at it. Here’s another example of transmutation How long does it take me type 5000 words No idea Me neither! What if I tell you that I can type 50 words per minute (I can’t type anything like that fast… but it keep the maths easy) 5000 words, 50 words per minute. 100 minutes. Words transmuted into time. At this point I wanted to insert a third example of taking someitnh comcreate and transmuting it into time. But I haven’t been able to come up with a good one. If you can think of one… enter it in to comments below. Where was I Distance…. Into time Words… into time The-great-example-you-just-thought-of into time. It would be mighty useful something like these that we could apply to software development. Trouble is.. Things in software that are ready to measure… … have drawbacks. Something like, say... Number of lines of code Number of functions Number of commits into source control These turn out to be bad choices: Measure lines of code… and you get lots of useless lines. Meaire number the functions... and you get lots of useless functions Measure commits… and you get lots of meaningless commits. In any case, these things all depend on coding - and coding comes to late in the process. We want something that could be applied to planned work. Enter the star of today’s show: the Story Point. The Story Points are used to indicate the “SIZE” of each … can you guess Yes. the size of each Story. Or Feature. Or task. Or piece of work. whatever. (I’m INTENTONALY using the word “size” here in the vaguess and broadest sense. We’ll tie it down in due course.) Story points share some of the properties of the “transmutable” things we looked at earlier. ONE - If one particular Feature is a 5 Story Point feature. We can each apply our own, personal transmutation. I might think that I could complete a 5 point Story in 5 days. A more gifted co
• Story Points - What's ... - Jak na to + styl
I've put it off long enough: time to dive in to Story Points!
Development That Pays, in ad revenue. Get to the useful content
This episode didn't work out as a well as I'd hoped. If the retention figures turn out to be bad, I'll re-make it.
Awesome.. Thanks so much Gary.
Really needed information about story points.
You're welcome!
One of my favorite subjects! And just in time, as we go into IP Planning today...
Excellent! Haven't written the next episode yet... so if you have any good tips... 😊
Got me really excited... for next episode.
I'm feeling the pressure!
I can’t wait to see where this goes.. I feel like there’s not much out there for this or for how people tend to organize and prioritize them..
Agreed!
I don't know yet whats coming next, but (using your style) I would add that "if you are measuring story points, you get lots of useless story points" :)
Ha! I guess I asked for that!
Your map of the UK is incomplete, you left out areas like Northern Ireland
Rather than using story points to estimate, consider COSMIC, which has been shown to more uniformly correlate with effort and which you could even use as a framework for adding items to your backlog. I've created a somewhat fun, and somewhat polished relatively quick introduction: czcams.com/video/HE6uq-geR7A/video.html
boss will ask why we spend 5 calender days to finish a 2MD work but the boss doesnt know how to ask why we spend 5 calender days to finish a 2 story points task ..lol
Hi. I'm an agile coach and just discovered your channel. Sorry to say that but I disagree with you about "there's no way to know the size of a story point". Velocity (story points) is not about guessing the future, it's about using the past to find similar tasks. What you have to estimate is the complexity. And by complexity, I mean : the functionnal behavior, the architecture, the technical unknowns, the experience, etc. The team builds a ladder of values (story points) she can use as a "Knowledge base" to find the good story points. It's only when you look to the past you can say a story point is x days or x hours. That's the strengh of Velocity, it's based on statistics from the past, relativley to the work already done.
GregB
I humbly do not agree full to what you just said .
Velocity is a long term indicator and not a short term . Relying on values from the past is not necessary the best possible solution and the reason for that is anchoring ,you are mentally influenced by previous behaviors and values rather than just focusing on the task at hand ..
If I tell you a jacket is worth 200 EUR from a previously 500 EUR discount , you are automatically inclined to buy it because your brain just a had a wiring of anchoring where you have compared two values that sometimes can have nothing to do with each other ..
Velocity is good as a starter , but in reality it should be just used a driver for slicing into smaller chunks of work .
My point :you will never know the Size of a story point and quit Franky it is not that important 🙂
Om shanti k good day please find
Thank you!
Useless hahaha!
Can't win em all!
talks a lot but dosn't say much!!!
Perhaps not my best work.
Your discussion of the maps is so infuriating. Any reasonably competent technical worker should engage with the concept in about 15 seconds.
Similarly with your discussion of the challenges of estimating in that if management measures (and rewards) line count or function count or commit count, the works will change their behavior to maximize those metrics. Nothing new about that. It has been an issue for at least 1.5 centuries.
The realities of these issues still don’t justify using the obtuse measure of effort of Story Points vs man-hours. Everyone I know really estimates in man-hours and then divides by 17 or some similar number. Then, those initial Story Point numbers are reduced in resolution to reflect the uncertainties of estimating while ensuring that the total Story Point count meets the agreed upon capacity.
On one hand, transforming the estimates from man-hours to Story Points is not a big burden. But, what value does it bring? None.
The more I learn about Agile, the more it reinforces my initial impression: Agile was developed by a bunch of immature punks as a stunt. The best example of this is the name they choose for the daily coordination meeting: Scrum. What happens in a scrum in a Rugby game is opposite in every respect to the objective of competent, technical workers collaborating to accomplish difficult tasks effectively.
Story Points reflect a similar immaturity. If Agile training instead spent 15 minutes discussing how to do estimating for work that is dominated by Unknowable Unknowns, you wouldn’t need to spend hours tutoring people on Story Points.
I'm not quite at the point of thinking that Agile was developed as a stunt...
... but I pretty much agree with everything else you've said here. (I'm now on a crusade AGAINST estimates.)
I will not follow you because you forced me to jump through several videos to get to the point and its annoying
Appreciate the feedback. I don't always get the "pacing" right - your not the dust to say this particular series took too long to come to the point.
Development That Pays like writing a user story does each video archive a desired outcome? Does it match the expectations off the title? I’m quite happy watching a video for 30-60 minutes than 3 to 6 10 minute videos
Why don’t you do an experiment re-edit a video to teach a single concept comprehensively
To the first point: I do attempt to make each video "complete" - a proper trajectory with a start, middle and end. But not all are a complete "User Story". Some concepts require conceptual building blocks. In this case, the *episodes* form the building blocks, the *playlist* the complete "User Story".
To the second point: my method of video production is time-intensive and my free time scarce. I could produce a 30 minute video every 10 weeks. You will know, I think, that delivering 3 "Story Points" every week for 10 weeks delivers *far* more value that 30 "Story Points" at the end of 10 weeks.
I did that a while back. The first video to "take off" was part of a set of three. I re-cut the set-of-three into this one: czcams.com/video/yUKYgotEEj0/video.html . It's 16 minutes long... and it did fairly well.