Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Eight points for one team is two points for another team

lloydatkinson.net

Post reply on HN
Print view View original

71–80 of 105 posts

Re: Eight points for one team is two points for another team

#71

Post by jrockway »

alistairSH wrote: post #33
jrockway wrote: post #8

I have never seen a ton of value in the exact number of story points, but they are a good way to have the "30 minute debate" that the author decries. If a task is so unclearly written that the team can't get a rough idea of the complexity in a reasonable amount of time, then it's a signal that the story can't be done or that something needs to change; more knowledge sharing, clearer success criteria for the story/tas…

I think the author was saying the 30 minute debate is a problem when deciding between 1 and 2. 30 minute debate over a "100" might be worthwhile, as long as you're doing it as part of refinement and not during planning.

Yeah, it's a trivial difference. If people are digging in that hard, that conversation seems like a good proxy for other problems with the team. I've had votes split between 1 and 2 a number of times. That's a 2.

(My planning poker algorithm is:

1. Vote without discussion.

2. If the votes all agree, that's the number of story points. If the votes are within 1 of each other (1, 1, 2; 2, 3, 3; 8, 8, 13) then it's the highest (2, 3, 13).

3. If there isn't that much consensus, then someone with the lowest vote and highest vote complete the sentence "To do this task..."

4. GOTO 1)

This is unbounded, of course, and sometimes no consensus can be reached. That usually means more definition is needed, and you can take on a task to do that definition for the next planning meeting. When there is disagreement, it isn't always bad. Sometimes an old hat will say something is a 1, and the new person that just joined the team will say that it's a 13, and the senior person will say "To do this task, edit foo.yaml and commit it." and the junior person will say "To do this task, I need to set up my workstation, then build a test environment, then read all those getting started instructions, then get access to production, ..." and you'll realize "Oh shit we never had the setup onboarding meeting" and you can just do that. Whereas if you just said it was a 13 and assigned it to the junior engineer, they still wouldn't be onboarded after struggling through all of that on their own.

I don't want to sound like an agile advocate or anything, in fact I'm pretty disillusioned by agile, but I've used this before and don't have a big problem with it. Looking at story points over a period of time is good for taking on the right amount of work in any given cycle; if someone says "we need to launch this next week" and your team does 15 story points of work per week, and the project is 1000 story points, then you know that that can't happen. Numbers to prove it! Someone can work on reducing the scope in the meantime. I think people try to get way too much out of agile, like on day 1 setting launch dates for features a year out, and that will never happen. That is why people are disillusioned, "I set up a 6 hour sprint planning meeting and bought a JIRA license, and we still aren't launching 3 new features a month!" Yeah, the actual work is still time-consuming; moreso on a larger team with changing opinions and changing markets. So it goes!

Re: Eight points for one team is two points for another team

#74

Post by rurp »

drstewart wrote: post #43
21723 wrote: post #2

Whatever Agile was, it's absolute garbage these days. It largely exists to hold developers maximally accountable to the business, at the expense of technical excellence or even maintenance, which can be expressed in its gun-language of Jira tickets and so get ignored. Fuck user stories, fuck sprints, fuck Jira, and fuck product management (a job in which one defines success by getting into one's boss's job as fast as…

>technical excellence Technical excellence doesn't pay the bills. Curious - what products do you pay for due to their technical excellence of their backend instead of the value they provide you directly?

There are a great many products I don't use, or use much less often, due to numerous bugs and painfully slow performance. Those qualities are highly correlated with engineering quality, in my experience.

Re: Eight points for one team is two points for another team

#75

Post by lloydatkinson »

Author here. Glad to see my article resonate with so many developers, both on here and reddit. I was expecting a lot of anger and spitting of feathers but as it turns out many people are really not happy with agile (or as I like to call it sometimes, badgile). I think, as an industry, we're all a little frustrated and fed up of this whole debacle.

Re: Eight points for one team is two points for another team

#76

Post by no_wizard »

nescioquid wrote: post #58
mickimnet wrote: post #20

Earlier quoted context omitted.

Not debating about estimating or not. I'm only replying to the example: CPUs can only execute, what the instructions tell them to do—like a production line—and not solve / create something (new).

Not sure why you were down-voted, but this is a good point. In fact, it is the base problem of all software methodologies. Planning depends on knowing how long an activity will take. Estimating is most reliable when you are estimating something you've already done before. Unless you're working in just such a low-novelty environment, your results will not be predictable and you should understand that the backlog is a…

Arguably however, Kanban frames them in such a way that both business (re: usually product) folks find them agreeable, and so do engineers.

If it reduces friction (as suggested) for both sides and everyone spends less time managing ceremonies as a result, then its a net win.

Re: Eight points for one team is two points for another team

#77

Post by msandford »

notjustanymike wrote: post #60
msandford wrote: post #45

Earlier quoted context omitted.

"Just demand the respect that the business isn't giving you. What's the worst that could happen?" You didn't say exactly that, but that's kind of the undertone of what you wrote. If you live in the US and you demand your right to a fair trial, well good on you. But if you live somewhere perhaps less committed to such a thing, making the demand doesn't mean anything other than you're naive and foolish. So it goes in s…

Sure, if you rephrase my remarks and change my geography you can certainly change the meaning of what I said.

The country analogy is to point out that not all places have the same values. Standing up for yourself might work at some companies. At others it might get you fired.

Re: Eight points for one team is two points for another team

#78

Post by js8 »

mickimnet wrote: post #20
js8 wrote: post #12

This reminds me of the now classic article: http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile... It essentially claims that "good agile" is Kanban, and Kanban is essentially abolishing of any forecasting in favor of actually doing the tasks, like the CPUs do when executing programs.

Not debating about estimating or not. I'm only replying to the example: CPUs can only execute, what the instructions tell them to do—like a production line—and not solve / create something (new).

My point was that OS dispatchers don't spend time working out how long things will take to compute, to allocate resources (such as CPU time) properly into the future; what they do instead is they just put the stuff to compute into a dispatch queue and go from there. Then if it's a novel thing or million times repeated thing doesn't really matter.

BTW, one indication that Scrum is bad is that nobody is doing its analogue (syncing everybody once a day?) in computing. Sane project management practices should be universal, and should also work for operating system schedulers.

Re: Eight points for one team is two points for another team

#79

Post by chester_the_dog » 

   I worked at a company where the scrum master told us that a story point had to be a fibonacci number.   Has anyone heard of this?

   The original Agile Manifesto demonstrates the collective wisdom of people who have written a lot of software.  Note that the Agile Manifesto doesn't mention a certified scrum master, or any role similar to it.  It says that business people and developers should work together.  It does not say that a certified scrum master should leave the stand-up meeting every morning to spend an hour giving a status report to the CTO.

Re: Eight points for one team is two points for another team

#80

Post by js8 »

nescioquid wrote: post #58
mickimnet wrote: post #20

Earlier quoted context omitted.

Not debating about estimating or not. I'm only replying to the example: CPUs can only execute, what the instructions tell them to do—like a production line—and not solve / create something (new).

Not sure why you were down-voted, but this is a good point. In fact, it is the base problem of all software methodologies. Planning depends on knowing how long an activity will take. Estimating is most reliable when you are estimating something you've already done before. Unless you're working in just such a low-novelty environment, your results will not be predictable and you should understand that the backlog is a…

I would say, if you absolutely need an estimate on how long a project will take (and often you don't), do a proper study on it, don't just pull a number out of your a*. Software project estimation is doable, but it takes some effort. It (IMHO) cannot be replaced by a clairvoyance seance, AKA planning poker.
Post reply on HN