Our team has recently embraced agile methods with gusto. I think when it comes to understanding how much work I can realistically get done in a fixed period of time, I keep it pretty real. That said, I'm confirming a few things about myself that I've suspected all along.
During our last planning session, I had a couple user stories to take point on. I estimated one at about 30 hours. For various reasons, we're in a short sprint, and 30 hours just happened to put me at 100% capacity. I estimated the other story at 16 hours. The agile trainer suggested that I defer the 30 hour story and we pull the 16 hour story in to the sprint. I suggested that I was totally comfortable with my estimate for story 1, and that it was probably on the high but safe side. We ended up pulling in the really safe story 2.
Now, I really wanted to work on story 1, but my assignment is story 2. No problem. It's Sunday night, and I've pretty much knocked out story 1. On a macro level, I'm driven by the desire to get on to story 2, but what's more interesting is that on the micro level, I'm really being driven by the iteration dashboard, and the desire to have "completes" on all my tasks.
So, I'm blocked on a minor item on story 1. I'm forcing myself to not blow out my time estimate by chasing things that someone else can probably fix quickly, but I REALLY want to see those last two tasks complete! This is really shaping up to be a sprint with 30 hour capacity and 46 hours of work delivered.
The moral of the story seems to be that in agile, you shouldn't buffer your projects as much as you do in non-agile planning. In non-agile planning, I would basically take the best case scenario and double the time. In agile, it seems like I might want to take the best case and multiply by 1.75 or something since the process already buffers you.
During our last planning session, I had a couple user stories to take point on. I estimated one at about 30 hours. For various reasons, we're in a short sprint, and 30 hours just happened to put me at 100% capacity. I estimated the other story at 16 hours. The agile trainer suggested that I defer the 30 hour story and we pull the 16 hour story in to the sprint. I suggested that I was totally comfortable with my estimate for story 1, and that it was probably on the high but safe side. We ended up pulling in the really safe story 2.
Now, I really wanted to work on story 1, but my assignment is story 2. No problem. It's Sunday night, and I've pretty much knocked out story 1. On a macro level, I'm driven by the desire to get on to story 2, but what's more interesting is that on the micro level, I'm really being driven by the iteration dashboard, and the desire to have "completes" on all my tasks.
So, I'm blocked on a minor item on story 1. I'm forcing myself to not blow out my time estimate by chasing things that someone else can probably fix quickly, but I REALLY want to see those last two tasks complete! This is really shaping up to be a sprint with 30 hour capacity and 46 hours of work delivered.
The moral of the story seems to be that in agile, you shouldn't buffer your projects as much as you do in non-agile planning. In non-agile planning, I would basically take the best case scenario and double the time. In agile, it seems like I might want to take the best case and multiply by 1.75 or something since the process already buffers you.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.