[HN Gopher] Story points are pointless, measure queues
___________________________________________________________________
Story points are pointless, measure queues
Author : brightball
Score : 75 points
Date : 2024-07-15 17:16 UTC (1 days ago)
(HTM) web link (www.brightball.com)
(TXT) w3m dump (www.brightball.com)
| quantified wrote:
| Story points were only ever an approximate unit of time. To fit
| them into a clear unit of time such as a sprint is a clear
| indicator of this. To call them complexity or anything else is
| misleading- transcribing a dictionary by hand into a CSV file is
| super simple (1 pt) and takes a long time (how many points is 3
| FTE-months in your calibration?).
|
| Eatimating effort-time vs completion time are quite different,
| serving different stakeholders. A story that takes 1 point of
| effort by anyone's pointing system could still take a week due to
| any number of factors (crucial collaborator gets sick, laptop
| crunched by a car, ransomware attack, whatever). The only really
| estimable aspect is how long the developer will spend on the
| work, not when it will be done. Air speed, not ground speed.
|
| That said, it's not clear how queue analysis helps when you
| haven't spent any time saying how long you might expect each task
| in the queue to be, or what the dependencies are between tasks
| within and across teams. Given engaged team members, I've gotten
| very good results on predicting the pace of progress for sprints,
| and it all never mattered because everything needed to be
| shipped. About 4-6 weeks before each X was to be completed we
| could say with confidence that X would be ready in 4-6 weeks. Not
| terribly useful.
| bboygravity wrote:
| I just don't get what the new terminology is for. Like how is
| this helping anybody?
|
| Manhours = story points Task = story Subtask = sprint Upcoming
| tasks = backlog Task turn around time = ?? Project goal(s) =
| epic(s)
|
| I'm probably not even doing this right, but what are we doing
| here anyway?!
|
| It gets real fun when the project involves software/firmware +
| mechanical engineering (think machines, robotics, etc), gotta
| love their faces when you teach them the special magic advanced
| project words for special software people.
| ozim wrote:
| But you have !sprints! and if you have laptop crunched you
| either have other dev taking over - so something else doesn't
| get done - or story that dev with crunched laptop is not going
| to deliver. That's just life and I also understand how
| disconnected management can be - but a lot of time you cannot
| say "exactly" when something will be done, because that is just
| not possible.
| andrewstuart2 wrote:
| Story points aren't time (as OP states). They're relative
| complexity, and uncertainty (hence the fibbonacci sequence
| building uncertainty in to larger numbers). And stories should be
| able to sized as big numbers. I've never been on a team
| comfortable with more than a 7, at least not since my first agile
| experience where we all took an agile/scrum training together for
| a few days. We'd frequently give things like 21 or 30 or 50
| points, as appropriate. That's the only place I've ever seen a
| burndown chart that looked like it should. Everywhere else, it's
| flat until the last day and then drops to zero as all those "it's
| a 7 I promise" get carried over to the next sprint for the 3rd
| time.
| ozim wrote:
| I agree - just countless times I have to beat that up into
| peoples head and even people who I would consider smart "points
| <> time".
|
| After the sprint you can kind of infer the time but it should
| not be guideline for next estimations unless these are tasks
| like "fix typos".
| throw310822 wrote:
| If they're not time, why use numbers? Use fruits: easy peasy,
| it's a lemon. A really tough story, a coconut. You can't add
| them in any case, because they're not time.
| ozim wrote:
| That is one of the complications - one thinks developers
| should be smart as in abstract thinking so they should
| understand (just like all the other numbers humanity made
| up): "numbers we call story points are not having property
| to add them and they are not convertible to time".
|
| * _Properties of Whole Numbers: Whole
| numbers are closed under addition and multiplication.
| Zero is the additive identity element of the whole numbers.
| 1 is the multiplicative identity element. It obeys
| the commutative and associative property of addition and
| multiplication. It satisfies the distributive
| property of multiplication over addition and vice versa.
|
| *_
| 1xdevnet wrote:
| I like this, I'd advocate for a fruit-based task system -
| although I suppose the exact fruit ranking would depend on
| the team.
|
| - easy peasy: lemon
|
| - easy but needs careful handling: kiwi
|
| - regular but boring: red delicious
|
| - regular, who wouldn't want to take one of these?: mango
|
| - large task, risk of splash damage if mishandled:
| watermelon
|
| - tough to crack, needs time or a hammer: coconut
|
| - technically we'll do this, but not really our job: tomato
|
| Edit: I am sad that emojis aren't allowed in comments,
| though it's understandable.
| icedchai wrote:
| If you try this (and I have, just not with fruits), someone
| will complain they can't graph fruits. You'll tell them
| that's the point. They won't listen, so they'll map fruits
| to numbers, and now you have the same problem anyway.
|
| My personal preference is to use time estimates with some
| uncertainty. A day or less. 2-3 days. A week at most.
| wewtyflakes wrote:
| Ultimately, we are bound by time, not complexity. Why does it
| matter how complex a task is? The product managers and
| customers wont care how hard we as engineers have to think or
| reason about a problem; to them, the only thing that matters
| is time until delivery.
| robertlagrant wrote:
| Story points aren't useful outside the team. They're for
| the team to help it figure out roughly how much stuff it
| can do each sprint. They shouldn't leak out of the team.
| throw310822 wrote:
| A sprint is a unit of time, how does measuring a
| "complexity"- whatever that is- helps in figuring out how
| much stuff you can put in *time*?
| robertlagrant wrote:
| I understand what you're saying - of course in some sense
| they're convertable. But the point is to not think about
| time when estimating, because if you estimate time you
| don't factor in things like other tasks, or holiday, or
| anything else. Or if you do you have to spend ages trying
| to account perfectly for time.
|
| Instead, if you estimate complexity (e.g. I think this
| task is a 3, just as a starting point, then this task is
| roughly the same, so it's also a 3, then this one is
| similar but will take almost as much testing due to its
| difficulty, so we'll call it a 5, then this one is very
| simple, not even half as difficult as the first one, so
| it's a 1, etc), then try and keep that up for a few
| sprints, then figure out how many points fit into a
| sprint, you automatically factor in other factors (like
| "I have to log into Okta ten times a day", or "people
| keep getting pulled into meetings") through practical
| observation of what got done, and you get better at
| predicting what you'll be able to achieve in a sprint.
|
| It's not perfect; it just removes the need for certain
| entire jobs devoted to accounting for time, which you can
| spend on another developer instead, while also being a
| reasonable measure of what you'll get done, and only
| takes about an hour every two weeks.
| recursive wrote:
| If the problem is "we're not accounting for holidays in
| our time estimates", I can't see how the solution could
| possibly be "time is obviously a flawed measure, so we'll
| use this other measure which has this hazy relationship
| with time, but we all agree that it's _definitely not
| time_ , although we have trouble saying what it _is_ "
| ozim wrote:
| But you don't estimate holidays in ... you estimate how
| long it would take if someone picks on the task Monday
| morning and works on it full time.
|
| If someone picks up task on Monday then has 20 other
| meetings - estimation is still the same, he just
| continues after those 20 meetings and you just don't care
| when estimating.
|
| Only thing is if at the end of sprint dude is saying "I
| started X then I had 20 meetings so I did not make it" -
| well you just accept that or you don't put guy into 20
| meetings.
| ozim wrote:
| So they are bad product managers and customers.
|
| Time until delivery for good managers and customers is a
| range. Can you estimate getting 10kg of potatoes from
| grocery store that is 35m driving roundtrip away? Can you
| say it will be exactly 40mins because you can pick up and
| pay in 5 mins? I don't, I can say it will take between
| 40mins and 2h. There are always things like card terminal
| stops working or you get stuck in traffic because of an
| accident.
|
| Complexity in that example is uncertainty like I do expect
| high traffic and there might be an accident happening but
| if there is less traffic and I hit all green lights 40mins
| going to be easy.
|
| We all know bad managers and bad customers will expect me
| to get that bag of potatoes in 37 minutes and then ask 10x
| why did I not drove over that police officer that was
| stopping the traffic because of an accident to get their
| potatoes on time.
| wewtyflakes wrote:
| I don't follow how we go from "they are bad product
| managers and customers" to... therefor time estimates are
| bad. I do not think it is unreasonable for our primary
| stakeholders to ultimately care about time. I also do not
| think it is unreasonable to give error bars in estimates
| like "this project is uncertain, therefor estimates will
| be variable".
| terr-dav wrote:
| I think time variability increases with the level of
| complexity. In this context I see the idea of task
| complexity being related to uncertainty in the time
| estimate. This makes it fit nicely with the Fibonacci
| sequence.
| recursive wrote:
| I continue to treat story points as a measure of time,
| despite being told repeatedly they're definitely _not_ time.
| I will continue doing this until someone can explain to me,
| in a way I can understand, what they _actually are_ that is
| not time.
| pests wrote:
| Difficulty level?
|
| You can't promise you can beat a game on hard 2x as fast as
| you can on normal, or 3x as easy.
| JohnFen wrote:
| Because in the end, they are a proxy for time. We can call
| them "complexity" or whatever, but that doesn't help much
| with planning a time-boxed period of activity. So they end
| up meaning "time".
| xboxnolifes wrote:
| Yeah, it seems like it's fairly common for people/teams to
| follow the idea that any story that is 8 or more points should
| be broken down to tasks of 5 or less. This simply doesn't make
| sense to me. If the most simple task is 1 point, is your most
| complex task allowed _really_ only 5 times as complex? Story
| points usually follow an exponential increase for a reason,
| enforcing staying in the mostly linear portion is just
| pretending the complexity and uncertainty has been decreased.
| IanCal wrote:
| The idea is that if a task is that large can you really not
| break it down into smaller steps? Do we understand the
| problem well enough to implement or are we hand waving over
| likely areas of complexity? Maybe if you tried to break it
| down you'd realise that the 21 point card is actually more
| like 10+ 5 points tasks and you had just though "big" not "I
| know what needs to be done and can size this accurately".
|
| Doesn't mean these cases never occur but it's worth seeing if
| it's actually smaller related pieces of work.
| jf22 wrote:
| I've personally had great success with story points.
|
| Success with story points comes when everybody realized they are
| useless for anything outside of a dev cycle and when you realize
| that the effort into making them somewhat accurate is the
| valuable part.
| KothuRoti wrote:
| My personal experience with story points is that the number never
| really mattered, but the process of the team discussing how to
| rate the complexity of a task was very useful. In terms of having
| utility of estimating how long something will take, I personally
| have never been able to translate story points into a reliable
| indicator for that for many reasons (e.g team changing, domain
| changing, variability in operational load outside of development
| work).
|
| Overall I tend to avoid using story points, but on the few teams
| I worked on who really wanted to use it, I always framed it
| around building shared understanding rather than a metric that is
| actually useful for estimating work.
| bsder wrote:
| In addition, I like the whole "Full Queues Amplify Variability"
| chart.
|
| It's intuitively obvious, but I never realized it was _that_
| bad.
|
| I'm going to have to run that down and see if it's _actually_
| backed by real data. Too many business books are complete
| flimflam.
| buescher wrote:
| Reinertsen's books are very, very good. The most recent and
| most up-to-date is Principles of Product Development Flow,
| which that chart came from. The previous one, Managing the
| Design Factory, is pretty similar and I think it's a better
| read.
|
| Another great takeaway from it is to prioritize things by
| cost of delay, or even better, what he calls Weighted
| Shortest Job First, where you divide the cost of delay by the
| expected length of the task. The only problem is that the
| same people that want to get oddly formal and inappropriately
| rigorous with things like story points will want to turn
| cost-of-delay into an accounting exercise - or object that
| it's impossible because they don't have the accounting system
| for it - which misses the point entirely.
| immibis wrote:
| "Plans are useless, but planning is indispensable."
| freitzkriesler2 wrote:
| Those items after your eg are part of the problem why story
| points don't work for you.
|
| You really do need to control the amount of time your devs get
| distracted by other things. If they're solely focusing on that
| one project, you'll be fine.
|
| Its why i personally appreciate XP more than plain old scrum.
| icedchai wrote:
| This, 100%. When engineers have focus, no context
| switching... things get done. When they're interrupted with
| useless Zoom meetings every 2 hours, productivity drops off
| the cliff. If you have 2 meetings 1 hour apart, that 1 hour
| is basically useless: by the time you're in the zone, you're
| interrupted again.
| shrimp_emoji wrote:
| > _I personally have never been able to translate story points
| into a reliable indicator_
|
| You haven't discovered the secret formula: make your estimate
| and then mindlessly triple it.
| khalladay wrote:
| multiplying estimates by PI has proven to be a scarily
| accurate rule of thumb over the course of my career.
| hnthrow289570 wrote:
| The points are needed because it's convenient to do reports
| based off of it. If we used estimation language such as "easy,
| medium, hard, dummy-thicc" they'd still need to assign points
| to those labels so they can do math on reports and graphs to
| watch your performance
|
| The biggest sin of course is then trying to predict velocity,
| but the consequences of that usually just make people doing the
| reporting look silly for no reason. I think even the slow
| developers rarely get fired, and you also get nothing for
| clearing more story points than other developers.
|
| No bonuses for higher velocity is the real reason no one takes
| it seriously.
| icedchai wrote:
| It's also easy to game the system. Turn a couple of 3's into
| 5's. Your "velocity" goes up for no real increase in work.
| cassianoleal wrote:
| > No bonuses for higher velocity is the real reason no one
| takes it seriously.
|
| Bonuses for higher velocity based on guessed story points
| would be an even bigger reason for not taking it seriously -
| or rather to overestimate everything in order to gain the
| impression of higher velocity and the bonus associated.
| hnthrow289570 wrote:
| Non-developers might have to learn something about
| development so they can push back on inflated estimates,
| which honestly would be helpful to everyone.
|
| If I quoted you $1,000 to unclog your kitchen sink trap,
| you'd call bullshit because you can probably find out how
| easy it is to do that. Likewise, if I quote you 13 points
| to add a generic error toast message because a POST went
| badly, you should call bullshit on that too.
| brayhite wrote:
| To your own point, the reports serve little value aside from
| a fabricated narrative that some companies like to build
| feel-goods around.
|
| Discuss the complexities and needs. Break the work into small
| chunks. Define what progress means. Set expectations for
| making progress. Regularly and honestly review why you/the
| team are or aren't meeting expectations. Rinse and repeat.
|
| Perhaps this is over simplifying it, but these are the tried-
| and-true high notes in my experience. If at any point one of
| those steps isn't feasible, then it's a larger issue that
| implementation process likely isn't going to solve, so the
| "to measure velocity or not" point seems moot.
| JohnFen wrote:
| This is my experience as well. Story points in and of
| themselves are worthless, but as an excuse to discuss the
| project as a team, they can have some value.
| d_watt wrote:
| I'm not sure I agree with the framing of this article.
|
| It seems to be comparing two different things, 1. Points as a
| method for attributing difficulty to a work item, vs 2. The
| collaboration process of creating a task list as a method of
| breaking down work.
|
| Running a team, I found pointing useful, more useful than the
| individual line engineers did, as we had different goals. My
| goal, in optimizing the team, was to go through all our work, get
| everyone in a room and create a relatively optimal plan for the
| next couple of weeks.
|
| By going through the exercise of pointing, we often found that
| something one person thought was hard, another found easy. That
| act of estimating would reveal knowledge one person had that
| another didn't, that made the task easier. Without that process,
| the work might have been harder do do, because the easy way was
| never revealed. We also adhered to a 8 points is too many
| philosophy that meant any item that hard needed to be decomposed
| to simple tasks to repoint.
|
| The "queuing" section basically implies the planning process
| should decompose tasks all the way to nothing but 1 point stories
| (or at least similarly sized work items within some variance).
| It's basically the same process as pointing, except not calling
| out some things are chunkier than others because it all comes out
| in the wash.
|
| TL;DR this articles definition of queuing is basically pointing
| where task = 1 point items.
| ravenstine wrote:
| We should be thankful that it's commonplace to use points instead
| of units of time like days even if points are horseshit.
| Estimates aren't that useful most of the time, and the last thing
| I would need is a manager telling me they're concerned because my
| ticket took 3 days instead of the two that the whole team
| estimated.
| ooterness wrote:
| As someone looking at algorithms for managing buffer bloat, this
| resonates.
|
| In IP routers, the goal is to keep the congested link busy. i.e.,
| Idle time from a momentary hiccup is wasted time. You need a
| small buffer to do this, but piling on more data adds latency
| without actually doing any good.
|
| Algorithms like CoDel realized that a lot of previous attempts to
| make this were noisy as heck. Minimum latency through the queue
| is the signal that makes sense. Everything else is misleading or
| gives inaccurate predictions. Why should it be any different for
| managing tasks for human workers?
|
| [1] https://en.wikipedia.org/wiki/CoDel
| mikeocool wrote:
| Given the size of my scroll bar, I rate reading this article a
| 13. My PM has decided I shouldn't bother reading it, as the
| likely value isn't worth the effort, because whenever we take on
| a 13, it ends up dragging on for like 4 sprints, and preventing a
| lot of other higher value/lower effort stuff from getting done.
|
| Maybe at some point in the future, we'll break the article and
| have a few people on the team each read it part of it for lower
| effort, and then synthesize their take aways.
| brightball wrote:
| Totally get it. :-)
|
| I did include a helpful TLDR near the beginning with the
| highlights though.
| jurassicfoxy wrote:
| This article was not written for the reader, but written
| because the writer loves to hear himself write.
| egeozcan wrote:
| Story points are pointless on their own, but estimation meetings
| are invaluable. In those meetings, story points serve as
| shortcuts for expressing gut feelings. However, after the
| meetings, they become completely useless, and even harmful,
| because, as the article mentions, people start treating them like
| precise numbers and do arithmetic with them.
| steveBK123 wrote:
| Story points are UBI for Product Managers
| einpoklum wrote:
| But my managers say I have to allocate story points! I'm sure
| they know what's best and not just making me jump through hoops
| because of their artificial imposition of JIRA under the title of
| being supposedly "agile"! Right?
| xn wrote:
| Estimate using time (hours, days, weeks, months, years).
|
| Reflect your uncertainty in your estimates using confidence
| intervals.
|
| If your confidence intervals are too wide, break down the work
| and estimate the smaller tasks and/or spend some time doing the
| work necessary to narrow your confidence intervals.
| psychoslave wrote:
| I can estimate rather accurately how much time it will take me
| to cook a meal assuming that:
|
| - I already mastered the receipt as I prepared the very exact
| same one many times in the past
|
| - I already checked that I have all the ingredients required at
| hand
|
| - I will cook in my own kitchen
|
| - no entropy engine (aka family members) was thrown before in
| the kitchen to put utensils in an other place than the place
| were I tidily store them (admittedly without conducting formal
| formation of the rest of the disruption forces)
|
| - no one will interfere because the way I do it is not the
| super fancy other way in which it could also be done
|
| - no external catastrophe happen which obviously need to be
| taken care of immediately, just at this point in recipe where
| by the time I will come back most of what I did so far will be
| better started again from scratch because the underlying laws
| of physics I was assuming so far changed so significantly that
| the left ongoing work is now utterly incompatible with the
| divergences that universe bumped to
|
| Meanwhile, in the easier transparent stationary landscape of
| software development, whenever I came with a to-my-mind-
| credible estimate for a non trivial endeavor, it was
| systematically rejected and superseded by a soon-to-be-blown-
| away deadline.
| psychoslave wrote:
| I find the requirement to give a note together is a good
| insensitive to stay focus on what the topic is, try to grab it,
| ask questions to start to put some lights on the biggest dark
| corner of the task.
|
| I couldn't care less about the resulting quantification. What
| matter is how well we communicate in the team, how helpful we are
| with each other, how well we can progress and keep motivation
| where struggle with huge hindrances paving the way. The points
| are not the point, but they are not pointless.
|
| The map is not the territory. Everyone can have a different map
| and a different metric system if any. If at the end of the day
| people inhabiting the territory do it in a satisfying way, all
| good. It doesn't matter much what the plan on the paper might
| look like: it will always be a mere epiphenomenal artifact of the
| actual human processes at play.
| Unknoob wrote:
| Story points are in fact time, and I'm tired of pretending
| they're not.
|
| You can sugar coat it all you want and say they represent
| complexity, but at the end of the day(or sprint), the higher the
| complexity, the more time it takes to complete.
| herpdyderp wrote:
| The problem therein is that that time depends on who is given
| the story. Perhaps that should be part of the estimation
| itself? (Who is working on it.)
| tetha wrote:
| The article lost me at a certain point, somewhere around the
| "solving the conondrum".
|
| It lost me, because we have two estimations - an overall size
| guess of an epic and an actual implementation estimation of an
| epic. Like the overall size guess is just 2-3 seniors looking at
| an issue and wondering if this takes days, weeks, months or years
| to implement.
|
| The actual implementation discussion is however what the article
| is talking about. We get most or all of the team into a meeting
| and we talk through what needs to be done, and structure all of
| that into individual concrete tasks everyone can have an idea of
| implementing them. And then we estimate those tasks.
|
| And this estimation in turn is communication to management. Like,
| we've realized that about 21 is what one of us can do in a usual
| monthly iteration outside of massive outages and such (we're an
| operational team). So if an epic turns out to require some 3 21's
| and 3 13's... that can easily take 6-12 months unless we put
| exceptional focus on it. With high focus... as a team of 4-5,
| that will still take 3-6 months to do.
|
| On the other hand, something that falls into a bunch of 5's and
| 9's and such tends to be muddled and struggled through regardless
| of whatever crap happens in the team much more reliably. It needs
| smaller chunks of overall attention to get done.
|
| And note that this communication is not deadlines. This is more
| of a bottom-up estimation of how much more or less uninterrupted
| engineering time it takes to do something. A 21 in our place by
| now means that other teams have to explicitly make room for the
| assigned person to have enough headspace to do that. Throw two
| interruptions at them and that task won't happen.
|
| It's more bin-packing than adding, tbh.
| jordanmorgan10 wrote:
| Or just lose Agile altogether
| xyst wrote:
| So basically a "kanban board" with priorities attached to each
| unit of work. Gotcha
| bb88 wrote:
| This is a problem from a management perspective, not a developer
| one.
|
| Story points are usable, but they're a "Wild Ass Guess" metric,
| not a true metric of actual work, and treating them other than a
| guess is fraught with problems. A 13 point story could fall
| somewhere between 8 and 21.
|
| Some stories we guessed 8, and ended up being more like 21
| (because the dev had to fight unexpected politics, or the API was
| billed as being "easy to use" but anything but.)
|
| All these are fine and should be fine to developers, except to
| management.
| 23B1 wrote:
| Project Management should be called Project Leadership, and the
| tools of the former should inform - but not dictate - the
| decisions of the latter.
| lmm wrote:
| The post is correct about some problems but completely wrong
| about solutions. Breaking down tasks that are already sub-sprint-
| sized in a meeting is the wrong way to do it; you'll put the
| boundaries in the wrong place and end up duplicating work, and
| then going overtime when the integration stage takes longer than
| you thought it would. The right place to do that breakdown is
| agile, just-in-time: give one person or pair/mob responsibility
| for a piece of user-facing functionality (that they've already
| agreed is sub-sprint-sized) and let them do whatever breakdown
| makes sense for that. If they get confused or stuck they can
| always raise it in standup (that's why we have them!).
|
| Similarly:
|
| > What happens when the team has turnover? What happens a few
| months down the line when this work comes back up based on the
| points that were given previously?
|
| Why would you ever put points on it a few months ahead of time?
| You do estimation in the sprint planning when it's a candidate
| for that sprint. There's no need to write down the reasoning for
| the estimation because the estimation is only relevant for the
| duration of that meeting (as you prioritise stories for that
| sprint), and _maybe_ in the retrospective two weeks later if the
| estimate was way off.
|
| I can see the argument for t-shirt sizes. The "queue" idea is the
| opposite, and has all the problems of point/time estimation.
|
| > When anyone not directly involved with the project asks why
| it's taking longer than they thought, the answer will be spelled
| out in the tasks list. These changes were added on these dates,
| for these reasons based on this feedback from these people. There
| is no "your estimate was wrong" situation. There is no "re-
| estimating" process. There's not even an ask to approve if you
| can change the point value. It just happens.
|
| Guess what? They're going to ask for dates. They're going to ask
| why the estimate changed, and not care about the answer because
| they just want to blame you for _their_ estimates being off. And
| your "tasks" have just become the same time tracking that you
| were (rightly) scared of; you have the same problem of having to
| do a bunch of pointless busywork to justify that you were
| actually working. (Suppose a "task" is suddenly twice as complex
| as you thought it was; now you've got to file a second "task"
| with a fake description to justify why you only did 3 tasks this
| week when Bob did 4).
|
| The problems the article identifies are: spending too much time
| and effort on estimation, estimating too far in advance (and then
| having the team and/or circumstances change), and treating
| estimates as deadlines. These are all real problems. But they're
| not problems with story points (indeed story points are actively
| helpful on the last one, since everyone has to at least pretend
| to admit that story points are not time estimates), and they're
| just as easy or difficult to solve whether you use story points
| or something else.
| Jtsummers wrote:
| > Why would you ever put points on it a few months ahead of
| time? You do estimation in the sprint planning when it's a
| candidate for that sprint.
|
| Because people (customers and managers in particular, but not
| just them) want to plan ahead, they can't escape the optimistic
| (and usually wrong) planning mode of BDUF projects. They fear
| uncertainty and want to know, at a glance, how long the work
| will take based on their current backlog/queue/whatever.
| Customers don't like to be told "We'll deliver when we deliver"
| so managers (salespeople) give an optimistic schedule now based
| on today's staffing (and optimistic assumptions about future
| staffing levels and future staff abilities).
|
| If they'd spend 5 seconds thinking they'd realize they can
| produce _and deliver_ most (but not all) systems in an
| incremental fashion that will satisfy the customers while
| leaving key decisions and estimations to be made when there 's
| enough information to actually make them. But that takes 5
| seconds and that's too damned long.
| jmward01 wrote:
| The fundamental issue isn't addressed but it sure is hinted at.
| Scheduling is an NP problem. As queue size, or backlog, or
| (insert thing here that tracks work to be done) grows it takes
| n^p calculations to schedule it optimally. This is hit on when it
| mentions small teams hitting their estimates. They can do this
| because their task list is small enough to go through all the
| permutations and actually come up with an accurate estimate. The
| only way to keep an n^p problem under control is to divide and
| conquer it. The leafs of that process must not go beyond a fixed
| size and the task divisions can't be recombined prematurely.
| Everything else is just yet another management idea that that
| will fall apart when the task has too many pieces. Once agile or
| any other management methodology acknowledges the fundamental
| mathematics at the core of things I may actually take them more
| seriously.
| duskwuff wrote:
| > Scheduling is an NP problem. [...] it takes n^p calculations
| to schedule it optimally
|
| That isn't what NP means. (An O(n^p) algorithm would in fact be
| in P.)
| T-zex wrote:
| What stops management from committing Feature A to be delivered
| after 250 tasks are completed? Yes the fact and the reasons that
| the Feature A expands to 500 will be documented, but who will
| care about it? This will still be a "delay" from the management
| point of view.
| JohnMakin wrote:
| Story points are a useful exercise when trying to discuss
| complexity of a task but IME it completely falls apart when used
| as a metric to determine anything useful like velocity.
|
| I had a terrible experience with them once. I was a relatively
| new, enthusiastic engineer on a struggling team of guys who'd
| been at the company a long time and were pretty burnt out.
| Inevitably I started getting all the "hard" stories with a lot of
| points, til it got to some stupid point where I was outputting
| about 80-90% of our team's combined story points. Management
| caught wind of it, didn't like it, so what they decided to do was
| adjust my points "downward" to be more in line with the rest of
| my team's output. It really irritated me, because it'd result in
| absurd situations where my teammates would get a "3 point" ticket
| that was like, just updating some field in a config file to an
| already-known value and checking it in somewhere, and I'd get
| this whole-ass project wrapped in a single ticket and they'd give
| me the same amount of points for it. And of course this was tied
| in to performance reviews, adding to how annoying it was.
|
| Another super irritating thing that would happen is I'd be asked
| to estimate complexity on some super vaguely defined ticket
| describing some problem that would take a lot of detective work
| to even figure out how to solve, so how am I supposed to give an
| accurate estimate of complexity? If I knew that much, I'd already
| have probably fixed whatever the issue was.
| fallinditch wrote:
| I think some of the problems and issues we're discussing here
| derive from confused project management methodologies that call
| themselves 'agile' yet require detailed estimation, measurement
| and reporting of task timing.
|
| Story point allocation can be useful to give a quick and easy
| 'good enough' estimation of time/effort required for a
| significant chunk of work (epic).
|
| I find that this approximate approach is almost always more
| accurate than trying to estimate every little task.
|
| If the project manager and engineers try to break down a project
| into small granular tasks with time estimates then it's almost
| inevitable that the effort will be underestimated because it's
| virtually impossible to anticipate every sub task, blocker,
| unforseen delay, etc (and then there's the extra time it takes to
| manage all these micro tasks in your PM system!).
|
| In such situations the old project manager trick of doubling all
| estimates tends to provide a more accurate timeframe.
|
| This is why story points can be more accurate: because you are
| estimating the effort it takes to do something _relative_ to your
| previous experience of similar workloads.
|
| So, if you avoid estimating granular tasks and keep your
| estimates as the approximate amount of effort relative to
| something you've done before, then you will end up with a more
| realistic timeframe. Story points can help with this mindset.
| Also your team will not have to waste time faffing around in Jira
| too much, or whatever system you use.
| rerdavies wrote:
| The value of story points is that it acknowledges that not all
| stories are equally time-consuming. Importantly, story points
| also provide a process for identifying stories that should be
| further decomposed.
|
| In my experience, story points allow forecasting that's as good
| as any forecasting method I've ever used. And I've used pretty
| much every schedule forecasting method over my long career.
|
| The author touches on many of the reasons why story points don't
| work. And pretty much every reason he gives is something that you
| are not supposed to do.
|
| The key to getting them to work is trust, and a commitment to
| never use story points as metrics to measure the performance of
| developers. Any attempt to do so will result in gaming of the
| system. The tradeoff that stories provide is lack of precision in
| exchange for not having to spend 50% of your development cycle up
| front doing detailed analysis required to provide detailed
| estimates (which never worked anyway).
|
| Things you must also never do:
|
| - compare calibrated burndown factors between teams.
|
| - Ask why the calibration factor isn't N. THe calibration factor
| is.
|
| - Have stories with more than N story points (where N is 3 or 5).
| Decompose them.
|
| - Introduce the least bit of stress.
|
| - Use burndown rates to generate commitments, instead of
| forecasts.
|
| - Use forecast results to justify asking developers to work
| overtime.
|
| The last point, I think, is particularly interesting. The manager
| who was my first scrum master made the following commitment to
| us: you will never work overtime again. And voluntarily working
| overtime will be consider a bad thing, not a good thing, since it
| impairs predictability of the team's productivity. "I know you
| don't believe me", he said. But he was right. We never worked
| overtime again.
___________________________________________________________________
(page generated 2024-07-16 23:01 UTC)