Agile Project Management: Part 2 of 2

[article]
  • Don't do this. It feels good, I know, but it's just creating cognitive noise where none needs to exist. Instead, estimate each task as if it's the only task you're completing. Later on we'll worry about dependencies and scheduling. Lots of little, simple things done repeatedly. Of course, if you have some monster task that has to be done first, like creating your development environment or setting up the network topology, that's going to be a huge item for every story. So just take it out, and later on you can add it back in as one of the initial things you have to do. If you'd like to break it out now and size it fine, but since these huge things have to be done no matter what, the relevant question is whether you can do them in one timebox or not, NOT how big they are. (think about it)
  • Estimate Before You Prioritize - Do not schedule or prioritize your work before you estimate. Studies have shown that people will think of something many months from now as being smaller than something next week. If you start telling people that certain items won't be done for six months, they're going to estimate the size smaller. So put it all on the table, and make sure that everybody is estimating the relative complexity as if we were starting on this item tomorrow . The only way to do that is not to show any sequence information before sizing. You can tell people to forget about what they saw, but it doesn't work that well.
  • Diversity is Good - Some texts will tell you that everybody on the team has to agree on the number for a certain task/story. That's nonsense. Diversity is a good thing. What I always do is tell folks that "the worst guess wins" -- the most pessimistic guesser is the one we're using. Of course, if you have somebody who's pulling the entire thing out of whack the team needs to talk to him, but "talking to each other" is the whole idea anyway, so there's no downside. Be careful with games and such that force quick unity. Unity is a great thing, but much more interesting is diversity and the reasons for it. Look at it this way: I can create a dozen games that let the team pick a number for a story, but it's impossible for me to create a game for a team to talk about the risks on a project and what's keeping them from delivering. Picking the number is the easy part: having the conversation is the tough part. Games (exercises) exist to create the conversation -- all the other stuff is window dressing. No matter how quickly you size up your stories, if you're not talking about critical project issues you're going to fail. Don't confuse the mechanics of something with the real purpose of it.
  • Attitude Beats Skill - Speaking of soapboxes, attitude plays a huge role in sizing. Remember that you're going to be sizing a lot in this project, so don't get out of sorts. After the first sizing effort, which can and should get chaotic, if you're taking too long to size each sprint start timeboxing your sizing efforts. The team is trying to learn, as a group, how to estimate how long things will take in this particular project . Nobody walks into the room knowing this, and the dynamics of the project keep changing from sprint to sprint. So it's a learning process, it's supposed to be chaotic, and it gets better

About the author

TechWell Contributor's picture TechWell Contributor

The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Nov 09
Nov 09
Apr 13
May 03