Lies, Damn Lies and Story Points


  • ♿ (Parody)

    @xaade said:

    The original Agile creed was much more of a spirit of ethics.

    Well, I don't really care what it started as. The other day I opened our JIRA and and saw something called "poker". I thought they included a poker game plugin or something, but it turned out to be some retarded "agile" gamification scheme for manchildren who can't do any work without pandering bullshit like this. And I'm still mad about it.



  • @blek said:

    poker

    You mean estimation?

    That's kinda vital to sprints.


  • BINNED

    @xaade said:

    You mean estimation?

    No, no, that's what a mentally balanced person would say and do, but mentally balanced people don't join cults, which is what "the agile movement" (:wtf:) is. "Planning poker" is when you take this incredibly simple, straightforward concept of "we need to estimate how long each issue will take to resolve", and then you develop an incredibly rigid procedure - basically a ritual, with special terminology and everything - around it.

    Seriously, read the Procedure section: https://en.wikipedia.org/wiki/Planning_poker#Procedure.



  • @blek said:

    "Planning poker" is when you take this incredibly simple, straightforward concept of "we need to estimate how long each issue will take to resolve", and then you develop an incredibly rigid procedure - basically a ritual, with special terminology and everything - around it.

    Some parts of it represent basic discipline.

    Whereas some parts are just speculative.

    For example, if someone is asked to estimate, they want the card turnover process to be sure that no one is influencing another person.

    In practice, you end up with several people who have no idea how the scope impacts the current codebase and shrug when they're asked what their estimate is supposed to be.

    I'd rather everyone who is comfortable that they have the appropriate knowledge to cast their vote, and then give others the opportunity object and explain why.



  • I'd highly recommend the concept of story points though.

    It turns out better estimates than hours.


  • Garbage Person

    Everywhere I've ever been, "Story Point" has been equated to either "an hour" or "a day".



  • Where I've been, they're equated to complexity.

    It was never a point to make sure they had a ratio to time.

    It's difficult, at first, to divorce the two, but once you do, for some reason, sprints were much easier to predict.


  • ♿ (Parody)

    My problem with story points is that you can't add them up to make any sort of intelligent statement. Our rule of thumb is 0.5 is a trivial thing, shouldn't more than a half hour. 1 is several hours, up to a day. 2 is more than a day, 4 is like 2 weeks, and don't even bother with anything higher.

    It's fine for looking at an individual issue but crap for aggregating to a sprint or anything of the sort.


  • Discourse touched me in a no-no place

    I've always been taught that you shouldn't equate story points to time. I'm not sure why, but various trainers have implied that the world will implode if you do.

    Our story points equate to "shirt size" estimates instead of hours. 1 is extra small, 2 is small, 3 is medium, 5 is medium large, 8 is large, and anything bigger needs to be broken down before it can go into a sprint.

    To give you an idea of how they relate to actual effort, our team has 5 developers and has a velocity of 70 over a 2 week sprint. We work 7.5 hours a day, 5 days a week.

    Here's what I've been taught:

    In sprint planning part 1 you should estimate your stories using points, and then measure the total against your team velocity to estimate how many stories you can do.

    (we never do this one) In sprint planning part 2 you should break down all of the stories into tasks, and estimate how many hours each task will take. You then measure the total against your available man hours to estimate how many stories you can do.

    You compare the estimates from both planning sessions to see if they vaguely match up. If they're wildly out, then you've got problems (you have to abort the sprint and start sprint planning again! Yeah, right!).

    Funnily enough, I've also been taught that burndown charts should be in hours instead of points. This seems strange to me, seeing as trainers have a weird fixation with story points.


  • ♿ (Parody)

    @DoctorJones said:

    I've always been taught that you shouldn't equate story points to time. I'm not sure why, but various trainers have implied that the world will implode if you do.

    Yeah, but I mean...you kind of have to. Unless you don't care how long a sprint goes or something.

    @DoctorJones said:

    To give you an idea of how they relate to actual effort, our team has 5 developers and has a velocity of 70 over a 2 week sprint. We work 7.5 hours a day, 5 days a week.

    But of course, it varies widely for different people. It's all bullshit artificial metrics that can help you if you can figure out how to use them correctly. I maintain that anyone who actively tries not to think of time WRT story points is TRWTF. But maybe we just think totally differently, and only one of us has any respect for deadlines or schedules.

    @DoctorJones said:

    Funnily enough, I've also been taught that burndown charts should be in hours instead of points. This seems strange to me, seeing as trainers have a weird fixation with story points.

    Honestly, I want to see both. We only show points, which is a major WTF to me. It makes no sense to have one but not the other. Combined, you have interesting information. Only one and you're wasting your time with data porn.


  • Discourse touched me in a no-no place

    @boomzilla said:

    Yeah, but I mean...you kind of have to. Unless you don't care how long a sprint goes or something.

    Our sprints are timeboxed to two weeks, regardless. We tend to get 70 points of work done, (although very rarely we've had to back stories out of the sprint because we've had problems). Story points are a vague metric, and sometimes we fuck up the estimates, but it seems to work out in the end. It took a few sprints to get the hang of it, but we've now got a feel for it.

    @boomzilla said:

    But of course, it varies widely for different people. It's all bullshit artificial metrics that can help you if you can figure out how to use them correctly.

    Of course, I was just trying to give you an idea of how much effort our points tend to equate to.

    The real problem with story points is when the team changes, suddenly your velocity is fucked because all of your metrics were bullshit vagaries in the first place.

    You know what doesn't change? Hours. It's strange that we're taught to ignore them though.



  • @boomzilla said:

    Yeah, but I mean...you kind of have to. Unless you don't care how long a sprint goes or something.

    The point isn't to ensure you fit within a sprint, but to judge over several sprints what your velocity is.

    As you judge your velocity, you can more accurately make predictions and guarantee your work.

    The reason this matters is that, a single task may be .5 hours for you, but 10 hours for someone else.

    By judging on velocity, you abstract that away.


  • ♿ (Parody)

    @DoctorJones said:

    You know what doesn't change? Hours. It's strange that we're taught to ignore them though.

    Yep.

    @DoctorJones said:

    We tend to get 70 points of work done

    The amount of points varies a lot for me. Again, because I can do maybe 5 story points worth of 0.5 stories in the time I can get a single story with 2 story points done. They aren't linear, so you can't simply add them up. Unless you actually translate them into hours estimates first.

    @xaade said:

    The point isn't to ensure you fit within a sprint, but to judge over several sprints what your velocity is.

    As you judge your velocity, you can more accurately make predictions and guarantee your work.

    AKA...fit the estimated work to a sprint!

    @xaade said:

    The reason this matters is that, a single task may be .5 hours for you, but 10 hours for someone else.

    Yes, of course. So I'll estimate a fraction of a point and they'll put it down as a full point or whatever. You're just fooling yourself if you don't think about hours when you think about story points for a single story.

    Don't get me wrong, I like the fuzziness of the metric, but that same thing makes it inappropriate for a lot of uses that people try to use it for.



  • @boomzilla said:

    Yes, of course. So I'll estimate a fraction of a point and they'll put it down as a full point or whatever. You're just fooling yourself if you don't think about hours when you think about story points for a single story.

    Well, maybe fooling yourself somehow works. I've been in teams that use points and teams that use hours, and points works better. Points lets you judge velocity, and it also obfuscates it from external people. Then you get in a habit of saying you can do 70 points of velocity, instead of saying everyone has 8 hours of work per day.


  • Discourse touched me in a no-no place

    @xaade said:

    8 hours of work per day

    Also, nobody has 8 hours of work per day, that would get in the way of all of the bullshit meetings... ;-)



  • Actually, we count 6 productivity hours per day where I work.



  • Realistically, that about right. IME and IMAO, that's about the most the majority of people can average in terms of productivity - and that the productivity usually drops if you try to push the working time past that for more than one week out of a six month period. The old formula of 60-80 hour workweeks that were typical during the Dot Bomb were actually one of the causes of that bubble bursting, and while most companies learned their lessons for a few years, you started to see that sort of thing becoming more common in the Web 2.0 period (though that generally got cut short by the 2009 recession). If it's starting to be a thing again now, that's a bad sign.

    This is true in any work environment, but especially true when the work is mental rather than physical - evolution (or whatever you think led to us) being what it is, we simply aren't constructed for long periods of intense thought. Desperation (e.g., during wartime when bombs are falling on your home, or when picking up the pieces after a natural disaster) can sometimes force people to push further than that without them breaking down in the moment, but even then the aftermath is usually pretty nasty. One of the reasons the Cold War didn't really get moving until around 1949 was because after the end of WWII everyone was literally too exhausted to start fighting again for several years, especially the leaders, planners and theorists.


  • ♿ (Parody)

    @xaade said:

    Points lets you judge velocity, and it also obfuscates it from external people

    Do your stories have a fairly consistent point value? Does your point scale vary linearly with hours? If so, I might believe you. Otherwise, it's bullshit, at least from an individual standpoint. Maybe you get lucky and it averages out?

    @xaade said:

    Well, maybe fooling yourself somehow works.

    Maybe. Do your story point estimates translate very well to the amount of time spent? If the answer is no, then you're doing some extra thing to translate between time and points. Or, you're consistently under estimating and hanging out on TDWTF to pad out the sprint.



  • @boomzilla said:

    Do your stories have a fairly consistent point value?

    Yes.

    @boomzilla said:

    Does your point scale vary linearly with hours?

    Not sure.

    @boomzilla said:

    Maybe you get lucky and it averages out?

    Yes. That's the point.

    @boomzilla said:

    Do your story point estimates translate very well to the amount of time spent?

    Yes and no.

    Can you give a ballpark figure on what a 13 pt will take? Yes. But it will vary wildly. Which is why you aren't concerned with the estimate of a single task, but rather the velocity, because it averages out.

    You become less concerned that the 13 pt task took a week rather than the average 3 days, and then you don't have external people saying, "That was supposed to take only 3 days!!!"

    External people see velocity and the ambiguity of it, and stick to expecting things on 2 week intervals.


  • Discourse touched me in a no-no place

    @boomzilla said:

    Do your stories have a fairly consistent point value? Does your point scale vary linearly with hours?

    Ours do. Whenever we do sprint planning, we always identify the smallest story, and then use that as a measuring stick for assessing the other stories, i.e. is this story bigger or smaller than that story? Is it twice as big, etc?

    We used to struggle quite a bit before we began using this approach.



  • @DoctorJones said:

    then use that as a measuring stick for assessing the other stories, i.e. is this story bigger or smaller than that story? Is it twice as big, etc?

    This is why the point system will have 1,2,3,5,8,13,20 as available numbers. A benefit to it, is that at 1-2 it's easy to tell if something is twice as big, but if you're worried about judging exactly twice as big 3-20, you can probably break up the task. Because you can't determine if something is a 5 or a 6, you're forced to pick 5 or suggest that it is significantly greater at 8.


  • ♿ (Parody)

    @xaade said:

    Can you give a ballpark figure on what a 13 pt will take?

    That would be like a year long thing in our scale. It gets broken up.

    @xaade said:

    You become less concerned that the 13 pt task took a week rather than the average 3 days, and then you don't have external people saying, "That was supposed to take only 3 days!!!"

    I get the external thing, but you should be worried. What went wrong? What did you not expect? If you aren't noticing stuff like that you aren't learning.



  • @boomzilla said:

    you should be worried. What went wrong? What did you not expect? If you aren't noticing stuff like that you aren't learning.

    You are, that's where sprint retrospectives come into play. You're just not worried about explaining that to outside people.

    But sometimes it's unavoidable.

    Estimation is a fickle thing.


  • ♿ (Parody)

    So, I took a look at my recent tickets and looked at my SP estimates vs the number of minutes I logged against each one:

    I didn't expect it to be so linear, but there you go. The big 0.5 outlier was a little more complicated than I expected, plus it got kicked back to me for some rework. Now I need to look at some of my cow-orkers to see how they've been doing.


  • ♿ (Parody)

    These results cover about a month, ending a week or so ago, BTW.

    Not surprisingly, most of the rest of these guys are terrible. This one is easily the worst (small sample size, she was on leave for a bit recently, but I think it's pretty representative)😄

    And for the entire team:



  • There's a lot to complain about with the "typical" agile project methodologies. I personally think the biggest one is that nearly every time, it completely misses the forest for the trees. When doing ISV work where you have a single product that is relatively simple (say, for example, a discrete mobile app with little outside communication), it is not a very bad option. But when you have an entire enterprise system being built by an "agile" team, things ignored early because of the laser focus on individual features ("user stories") leads to a terrible result.

    For example, the database objects that are created by a team focusing on individual features inevitably end up non-relational, with the database not at all reflecting a model of the underlying business reality being modeled. Some teams try to get around this by saying "we do code first", which just means "we don't really care about anything data related" - so long as the screen that shows the individual record looks OK, or that an individual invoice is generated, or that the customer data can be displayed on the screen. Bugs lead to data anomalies that are super expensive to fix later, migrating old data into the system becomes virtually impossible, and good luck figuring out analytics and reporting, which is always a late addition. And the choices made early "oh I know lets use a 'document' db so its easy to load the screens with JSON data" lead to awful things later - "crap i have to parse every JSON object in the database in order to add up the total $ spend by week by account rep".

    Yes, the business will make different choices as time goes on over the project. But the underlying reality of what the system is trying to model needs to be thoroughly understood. Most agile projects ignore this in favor of delivering something.


  • Java Dev

    We've mostly stopped recording estimates with the shrinking team, but I'll put up a post defending planning poker itself as a process, disjunct from the story point question: It allows/forces the less vocal members of the team to participate in the estimation process.



  • I like planning poker as well. Of all the things in Agile, I'd probably be most likely to adopt that first. (And regular retrospectives. Also a good idea.)


Log in to reply