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

81–90 of 105 posts

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

#81

Post by nine_zeros »

notjustanymike wrote: post #62
nine_zeros wrote: post #34

Earlier quoted context omitted.

When there is so much overhead in process, the process is a waste of time. Management needs to skill up.

Oh management absolutely needs to skill up. One of the major reasons Agile annoys engineers is because the process is owned by an individual who doesn't understand why they're doing it, or how it can be changed. Personally, I've found retros to be most important area for a manager to focus. They can be a wonderful source of discussion and improvement for the team, or one of the most boring hours of your week.

Having been in 300 retros, I assure you that the process overhead is large enough that any other process is more efficient at this point.

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

#82

Post by etblg »

chester_the_dog wrote: post #79

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 t…

Fibonacci story pointing is good, at least in my opinion.

It removes a lot of the granularity of pointing, and forces the larger points to grow very fast. You still have some nuance between 2, 3, and 5 pointers, but once you start getting past that the numbers jump to 8, 13, 21, very fast. You don't need to spend time with your team debating whether something is a 5, 6, 7, or 8 pointer, it's closer to a 5, or its closer to an 8, if it's higher than an 8 it jumps up to 13. Less time spent circling around an exact number and quicker to get to a "is big" "is medium" "is small" "is trivial" decision.

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

#83

Post by doctor_eval »

js8 wrote: post #80
nescioquid wrote: post #58

Earlier quoted context omitted.

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.

I’ve said this previously but I don’t agree that software estimating is possible in theory. It’s a form of the halting problem. You can’t, even in theory, know how long something will take until you do it.

It’s certainly possible to estimate to a rough-order-of-magnitude but the problem is that the ROM quickly becomes a target, and then a commitment.

I have a couple of positions that I take.

First, the old adage still applies: “better, faster, cheaper - choose two”. If you set a deadline then you have to be willing to drop features or quality, because Brooks already demonstrated you can’t add resources after you start.

Second, if you do need to set a deadline then prioritise it, stick to it and celebrate it. Too many times deadlines are used as a whip, and my or my team have wiped themselves out to meet it, only to be told it wasn’t really needed. This is insanely demoralising and strongly affects productivity in the long term.

My personal (and unpopular) preference is to prioritise completion of stand-alone features rather than building to deadlines, which means you can release a product at almost any time with fewer, but better quality features. This approach has a demonstrable positive impact on the ROI but because it’s more complex and provides less short term certainty, it’s frowned upon.

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

#84

Post by BaseballPhysics »

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.

> Kanban is essentially abolishing of any forecasting

This isn't even remotely true. Kanban establishes specific measures, including throughput, that, combined with statistical modeling, specifically allow for forecasting to be done.

Do you really think the car industry, where Kanban originates, doesn't care how many cars they're going to produce in a quarter, or whether they're ahead, behind, or on track on hitting their targets?

Come on.

The idea that "forecasting" and "agile" are somehow at odds with one another is a gross misunderstanding of both.

Edit: As an aside, that article's use of Google as somehow the paragon of software development superiority really dates it. Google is notorious, at this point, for being an unreliable software development organization. They fail to listen to their users by building features people don't want, canceling projects that vocal users do want, and shipping incredibly buggy products (Android 12, anyone?) All of this is, at least in part, caused by many of the problems the blog post highlights but claims have been resolved, including a lack of strategic cohesiveness and issues with building and maintaining staffing for projects that are no longer sexy.

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

#85

Post by forgotmypw17 »

I've worked on about 10 different teams using some variant of Agile, and I only recall one which was able to achieve accurate estimates for a complex software product... What's the secret?

Story points are only the beginning. They are an estimate which must be updated during the planning meeting. Our planning meetings for a team of fewer than 10 people took the better part of an entire workday -- 8 hours.

What we did during those meetings was pick apart the user stories into small developer tasks until there was no task larger than 3 story points on the board, ideally all of them one-pointers, with one point being an estimated 1 hour of work.

We also spent most of an entire day for each retro meeting.

Edit: Our definition of done was signed off by the QA Engineer.

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

#86

Post by js8 »

doctor_eval wrote: post #83
js8 wrote: post #80

Earlier quoted context omitted.

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.

I’ve said this previously but I don’t agree that software estimating is possible in theory. It’s a form of the halting problem. You can’t, even in theory, know how long something will take until you do it. It’s certainly possible to estimate to a rough-order-of-magnitude but the problem is that the ROM quickly becomes a target, and then a commitment. I have a couple of positions that I take. First, the old adage stil…

I think in pure compsci theory you might be right, but in practice (industrial SW production), we usually limit ourselves to algorithmic solutions that do not involve halting problem, so estimation is possible. For example, an upper limit for a rewrite of a system is how long it took to create the original system (provided you understand the tradeoffs and issues of the original architecture).

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

#87

Post by lloydatkinson »

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…

> 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,

Author here, this was one of the motivations for writing this and the other article linked at the start. I've seen agile actively harming maintenance and quality more times than I've seen it ever help maintenance or quality.

You know things are fucked up when you need to put technical debt, refactors, library updates, etc down as "stories" (erm hello, where is the customer story in "fix that giant performance TODO") instead of just doing them. Sure, we can just carry them out to avoid the wrath of the scrum master and co, but then you have to balance time between doing the stories, and fixing bugs.

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

#88

Post by lloydatkinson »

thenerdhead wrote: post #7

This is so true. I've been on teams that did 100x work with like 3 engineers. I've also been on teams that do near 0x work with over 10. What I can confidently state is that you must work the people and then the process to improve anything. We need to stop adopting things just because other teams use them or because they are an "industry norm". If we just truly kept true to the original agile manifesto, there would b…

I felt this deeply

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

#89

Post by lloydatkinson »

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.

This is exactly what I meant. I thought it was clear, if they read it back it says "but" in that point.

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

#90

Post by lloydatkinson »

arpanet86 wrote: post #30
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…

Not having good definitions of done is also a great way for a team to feel like it's treading water eternally. Small, achievable goals are a hack for team morale. (The trick is making sure that the small, achievable goals roll up into valuable long-term work.)

Very true. Experienced this often. Not seeing goals result in anything is a motivation killer.
Post reply on HN