Edwin Goddard @heedfull

If you assigned 1 story point to every story, how much slicing would you do before you were confident you could actually complete each story in a day or so? Congratulations! You just discovered #NoEstimates. Stop trying to fit the estimate to the story. Start slicing the stories.

@rainbowinverted @allenholub When working collaboratively in a mob or ensemble you can get great focus when everyone is aligned and working together to solve the same problem. All of the experience and perspectives of the team can be brought to bear. From personal experience it's amazing what can be achieved

So many of the comments I hear about estimation boil down to "but we have to plan and meet our goals." That's a deep failure to grasp the concept (of agile ways of working). We plan strategically, and our goals are strategic. The details of what we have to build to meet those strategic goals are discovered incrementally by releasing small bits of valuable software and getting feedback on it. We defer details, in other words, to the last responsible moment. Defining those details too early doesn't really work because the customers themselves won't know what they need until they have something in their hands. The details are invariably wrong. Too-early focus on details also often leads to building things nobody wants or needs. There are occasional exceptions, of course, in the corners of the program where regulations, or the actual behavior of actual hardware, or necessary algorithms apply, but those bits comprising the entire system are exceedingly rare.

Maybe instead of #NoEstimates, it should be #WhyBother. We all know they don’t work. Estimates are the worst sort of productivity theater, given that nobody believes that they’re even close to accurate.

Travis Hubbard @wtravishubbard

2 years ago

Dev lead said the project would take 9 months from start to finish that was 2 years ago

193 103 2K 447K 111

@Madisonkanna I just stopped doing it and either gave a story a 1 (small enough/right sized) or gave it whatever the biggest number was for too big and needs breaking down IMO that's all you need and then you can focus on flow

A Sprint is NOT a mini project. You DO NOT commit to finishing some specific bit of work (or be somehow penalized if you don't "finish" on time). It's NOT about completing stories (or, horrors, retiring tickets). That's all nothing but control-focused waterfall management bullying people into working in ineffective ways. A Sprint has a _goal_, not a target. E.g.: "make our customer's life better in this product area" or "help the user do X." Anything you can build that moves the product in the direction of that goal is just fine.

@antzzzm @allenholub @WoodyZuill Don't you love being taken out of context. The point I was trying to make was to use that investment (the team) the most effective way (building the most valuable thing with the customer) rather than wasting time estimating things, that's a sure why to not deliver and get fired

@HarryBailey @allenholub I wasn't talking about two teams. In my experience, the best products are built by teams that talk directly with the users and can collaboratively build it piece by piece

@WoodyZuill @antzzzm @allenholub I like to think of a development team as a fixed cost. How would you like them to invest their time. Give them something to work on and periodically review are they making progress to the goal. Is the thing they're working on still the most valuable, if so keep going if not pivot

Estimates are not needed for choosing what work to do. The only thing that matters is customer value. If something is essential to the customer, you cannot choose not to do it. If it’s not essential, don’t work on it at all. Admittedly, they may be useful for cost-of-delay computations, but you don’t need an “estimate” beyond high-medium-low for that.

Ralph Galantine @RalphGalantine

2 years ago

@allenholub @dodgerfan_mike @ultramaximalmax Holding people to estimates is stupid and counterproductive. Estimates are needed for choosing which work to do. Value to be delivered must be compared to expected cost. T-shirt sizing is a good tool. Story points are often misused, but can also be a good tool.

1 0 3 14K 1

@alfbarbola @allenholub Which is fantastic because it makes the whole team better!

@Martien @allenholub Let the people doing the work decide the best way to do that work and to structure themselves "The best architectures, requirements, and designs emerge from self-organizing teams."

Backlogs are a Scrum thing, not an Agile thing. Customer-driven shops that work with agility decide what to do next by doing the current thing (and getting feedback). The decision is driven by strategic planning, but backlogs are entirely tactical.

Well written blog post. Told me exactly what I needed to know in really succinct and well written way. Thank you @madnan_rafiq adnanrafiq.com/blog/how-to-ad…

@davefarley77 Build's broken

Report to boss: "Reactionary decisions with vague objectives and artificial boundaries executed by ad-hoc groups have led to technical debt and low morale." Boss: "How could this be? Quick; Get some of our top people and give them 3 months to solve this!!" #leadership

The product owner's job is NOT to tell the team how to do its work or what to work on. They "order the backlog" but it's up to the team as a whole to decide "who does what, when, and how." A PO is ***not*** a manager. They tell nobody what to do. Their job is to understand the market as a whole, to arrange conversations between the team and the customer (they are **not** an intermediary between the two), and to organize the work by value. That's it. What they do is nothing at all like the old Business Analyst job. They are ***a team member*** who specializes in product development.

TJS @XerWoman

2 years ago

@allenholub Yup , but what should the team member do when they report about spending 3 hours on “non-story” task and Product Owner throws a fit ?

4 0 4 49K 1