[eberyvody]

ended with a cliffhanger! OP eloquently picked apart the predominant system without a clear alternative :)

mostly agree with the premise though, and I'll add that "sprint" is insane nomenclature for something that you do continuously week-in and week out.

my question for the author (and ya'll) is how to reconcile the time-waste of estimating with the fact that you do indeed need some estimate of how long something is going to take in order to decide whether you should prioritize doing it (we like RICE [0]). as the designer on a startup team, i'm not going to push for designing / building some crazy VR UI no matter how much we hear a customer asking for it, but i'll definitely design some 3d button transform hover states or other small finesse if the front-end eng says it's easy to implement. i'm sure i can think of a less extreme example, but not today.

[0]: https://www.intercom.com/blog/rice-simple-prioritization-for...

[ellius]

My most recent team ran a version of XP, and I found IPM (iteration planning meeting) to be one of the most effective and important things we did. We had a very good back and forth with our Product Manager, with conversations usually going something like this:

PM: Let's go through our prioritized features. First we would like Feature A.

Team: That's probably easy, we can do it in a day or so.

PM: Great. Next we need Feature B. I know this one looks a little more complicated.

Team: Yeah, that's more like a week.

PM: That probably isn't worth it to me. We can probably push this feature back a couple releases, and maybe take out part of it.

Team: Would it help if we just did Part X? That seems like it would give you most of the value and it would be much easier.

And so on. The constant cost-benefit analysis, reprioritization, and rescoping was a great lever and made the team very productive.

The other 4 things, all related I think, that made us effective were:

• Everyone sitting together. I could go ask the designer or PM a clarifying question at any time.

• TDD. I would constantly start to write a test and realize that something didn't make sense—some assumptions were conflicting, or we needed to do another story before the one I was working, etc.

• Pairing. Many times I'd have written the test, had cleared my plan with the PM, and my pairing partner would point out a different perspective or catch one of the things I described above.

• Frequent releases, about quarterly at first and down to bi-weekly at one point.

In all cases, what we were really doing is optimizing the value of NOT doing things. We were helping the PM understand her costs, but we were also helping her eliminate huge chunks of wasteful work, e.g. building things users didn't want, things that didn't integrate well, and so on. Estimating was a piece of it, but it was really the buy-in from the business to accept our estimates and more importantly to trust us as partners in the scoping and planning process, and doing that process fluidly, that made us successful.

[bobm_kite9]

> ended with a cliffhanger! OP eloquently picked apart the predominant system without a clear alternative :)

Author here. Yes, another comment made the same point. But I'm glad you feel what I covered was eloquent. Often, diagnosing exactly what the problem is takes you a long way towards solving it.

As I said in the other reply, I will post the follow-up to this article in a few weeks which will outline where I am going with this: I'm building a multi-part series looking at estimating in software development, so Sprints are an important aspect.