5 ms·

> The way to do this well is to break down a feature until they’re at about half-day sizes tasks. I have never seen that work in practice.

mohaine 8y ago
Breaking a task down into meaningful half day task is almost as hard is just implementing it, but usually this is attempted in a committee setting. This is not a recipe for success.
- khyryk 8y ago
  Agreed. Think of how ridiculous it would be to make a half-day task for figuring out X -- sometimes I've spent days, even weeks, trying to figure out how a module works. In practice, being able to break things down meaningfully and accurately to such a minute level implies that a lot of time was spent in grooming, which means we're just back to waterfall again. (Or the tasks at hand really are just that simple and/or the people involved have a lot of expertise.)
trey-jones 8y ago
I agree. Saying, "Break it down until it's in half-day size tasks" is fine. Some of the things that might interfere: 1. Are you sure you can do that in half a day? 2. You forgot about this one part of the task that you thought would take half a day. 3. There was a bug in the plugin that you were going to use to do this task in half a day, and you spent three days fixing it. 4. This task will actually take longer, but management won't buy that. Looks like it should be half a day on paper, so that's what we'll say. 5. I've never even done this one thing before, but it sounds like it should just take a couple of hours. I understand the concept - trying to say something will take a week is even more error prone. But I think most of us are still pretty bad at estimating a budget for tasks even at such a small scale.
commandlinefan 8y ago
I've never even seen it work in theory.
- deleted 8y ago
  [deleted]
ItsMe000001 8y ago
When I read that in OPs comment I immediately had to think of "How to draw an owl" (the meme version, not one of the serious online lessons -- https://pbs.twimg.com/media/DcC1YEyVQAA9Lkw.jpg https://pbs.twimg.com/media/DcC1YEyVQAA9Lkw.jpg). "You simply break the task down into all its parts, then you just do it. Projects are easy." Not to mention that that approach only works if you produce another version of something you already produced many times. There certainly are such development efforts, for example, I think anything data- and form based, like data entry + database + some reporting, what used to be paper cards a long time ago, and then punch cars, those type of apps can probably be made using that method. So that's when they had to build the freight version of the Boeing 747. Then they thought "that was easy", and started the Dreamliner, something very different that they had not done before... (and it even still is an airplane, so not even that outrageously different as different pieces of software can be) I think the "break it down" approach also faces the problem of the "coastline length measurement". I'm also reminded of an anecdote from my early days with computers: I had to write an assembler routine (as part of an 8 bit assembler program) that seemed too hard, so I outsourced it to someone else. He didn't know what to do either, so I explained it to him. When I was done I realized I had just implemented that difficult function - I wrote it down in half an hour and that was that. Planning well, finding out what to do, is harder than the actual programming. Again and again, in all projects, I find that the >90% part is finding out what to do. There are stories from projects that lost all their code, years of work, and they thought they were done and finished (business kaputt) - but when they rewrote the software they fond it took them only weeks or instead of years. When you already know what you want and how the end result is supposed to look like (and feel and behave) then writing it in code is the easy part.
- kareemm 8y ago
  > Planning well, finding out what to do, is harder than the actual programming. Again and again, in all projects, I find that the >90% part is finding out what to do. There So you've advocating an approach where you... don't plan? I'm confused. Perhaps you're getting too hung up on the half day part? That measure is a useful forcing function that ensures the dev team has thought through the approach in enough detail to identify where the risks are and what smart trade-offs can be made.
williamdclt 8y ago
I'll go against all the other answers and say that I have seen that in practice. I'm even doing that in practice, every day of the week. A half-day task would even be a big task, most of our tickets are a couple hours maximum. We practice a lean-laced Scrum with 1-week sprints. And yes, it works. And yes, we go fast. So yes, it can work (thought we have several years of refining our methodology and have a big culture of pragmatism and problem-solving).
- trey-jones 8y ago
  Do you mind putting out a number of hours (per dev team) that get spent in Backlog curation, story generation, and other budget planning every week? I think perhaps an important missing ingredient for getting budgets right is actually spending the time to do so. The smaller the company, the harder it seems to justify. Indeed, for a lot of us in smaller companies, getting our clients to actually consider taking an agile approach at all is a stretch.
  - williamdclt 8y ago
    For a team of 3 devs + 1 scrum master: - Backlog refinement/grooming: 1.5 to 2h, 1 dev + SM (+ PO) - Technical refinement: 1.5h, all 3 devs - Sprint review + retrospective + planning: 4h, all 3 dev + SM (+ PO) Story generation is done by the PO, that's most of his job (though we split stories during backlog refinement if needed). I don't know if it sounds like a lot (I feel like it could), but turns out it's actually efficient, every minute of each meeting is productive because we know exactly what we're going in for, how it will go and what you want to get out of it!

mohaine 8y ago

Breaking a task down into meaningful half day task is almost as hard is just implementing it, but usually this is attempted in a committee setting. This is not a recipe for success.

khyryk 8y ago
Agreed. Think of how ridiculous it would be to make a half-day task for figuring out X -- sometimes I've spent days, even weeks, trying to figure out how a module works. In practice, being able to break things down meaningfully and accurately to such a minute level implies that a lot of time was spent in grooming, which means we're just back to waterfall again. (Or the tasks at hand really are just that simple and/or the people involved have a lot of expertise.)

trey-jones 8y ago

I agree. Saying, "Break it down until it's in half-day size tasks" is fine. Some of the things that might interfere: 1. Are you sure you can do that in half a day? 2. You forgot about this one part of the task that you thought would take half a day. 3. There was a bug in the plugin that you were going to use to do this task in half a day, and you spent three days fixing it. 4. This task will actually take longer, but management won't buy that. Looks like it should be half a day on paper, so that's what we'll say. 5. I've never even done this one thing before, but it sounds like it should just take a couple of hours. I understand the concept - trying to say something will take a week is even more error prone. But I think most of us are still pretty bad at estimating a budget for tasks even at such a small scale.

commandlinefan 8y ago

I've never even seen it work in theory.

deleted 8y ago
[deleted]

ItsMe000001 8y ago

When I read that in OPs comment I immediately had to think of "How to draw an owl" (the meme version, not one of the serious online lessons -- https://pbs.twimg.com/media/DcC1YEyVQAA9Lkw.jpg https://pbs.twimg.com/media/DcC1YEyVQAA9Lkw.jpg). "You simply break the task down into all its parts, then you just do it. Projects are easy." Not to mention that that approach only works if you produce another version of something you already produced many times. There certainly are such development efforts, for example, I think anything data- and form based, like data entry + database + some reporting, what used to be paper cards a long time ago, and then punch cars, those type of apps can probably be made using that method. So that's when they had to build the freight version of the Boeing 747. Then they thought "that was easy", and started the Dreamliner, something very different that they had not done before... (and it even still is an airplane, so not even that outrageously different as different pieces of software can be) I think the "break it down" approach also faces the problem of the "coastline length measurement". I'm also reminded of an anecdote from my early days with computers: I had to write an assembler routine (as part of an 8 bit assembler program) that seemed too hard, so I outsourced it to someone else. He didn't know what to do either, so I explained it to him. When I was done I realized I had just implemented that difficult function - I wrote it down in half an hour and that was that. Planning well, finding out what to do, is harder than the actual programming. Again and again, in all projects, I find that the >90% part is finding out what to do. There are stories from projects that lost all their code, years of work, and they thought they were done and finished (business kaputt) - but when they rewrote the software they fond it took them only weeks or instead of years. When you already know what you want and how the end result is supposed to look like (and feel and behave) then writing it in code is the easy part.

kareemm 8y ago
> Planning well, finding out what to do, is harder than the actual programming. Again and again, in all projects, I find that the >90% part is finding out what to do. There So you've advocating an approach where you... don't plan? I'm confused. Perhaps you're getting too hung up on the half day part? That measure is a useful forcing function that ensures the dev team has thought through the approach in enough detail to identify where the risks are and what smart trade-offs can be made.

williamdclt 8y ago

I'll go against all the other answers and say that I have seen that in practice. I'm even doing that in practice, every day of the week. A half-day task would even be a big task, most of our tickets are a couple hours maximum. We practice a lean-laced Scrum with 1-week sprints. And yes, it works. And yes, we go fast. So yes, it can work (thought we have several years of refining our methodology and have a big culture of pragmatism and problem-solving).

trey-jones 8y ago
Do you mind putting out a number of hours (per dev team) that get spent in Backlog curation, story generation, and other budget planning every week? I think perhaps an important missing ingredient for getting budgets right is actually spending the time to do so. The smaller the company, the harder it seems to justify. Indeed, for a lot of us in smaller companies, getting our clients to actually consider taking an agile approach at all is a stretch.
- williamdclt 8y ago
  For a team of 3 devs + 1 scrum master: - Backlog refinement/grooming: 1.5 to 2h, 1 dev + SM (+ PO) - Technical refinement: 1.5h, all 3 devs - Sprint review + retrospective + planning: 4h, all 3 dev + SM (+ PO) Story generation is done by the PO, that's most of his job (though we split stories during backlog refinement if needed). I don't know if it sounds like a lot (I feel like it could), but turns out it's actually efficient, every minute of each meeting is productive because we know exactly what we're going in for, how it will go and what you want to get out of it!