Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

The Bare Minimum

When it comes to project management, I tend to favor the less-is-more approach. For the most part, I think teams should be self-managed and organized. I’ve never seen project managers actually add value – they merely get in the way and slow teams down. That isn’t to say that I favor cowboy engineering, I just happen to think that software developers are better equipped at managing a project than so-called project managers.


Regardless of which software development methodology and hierarchy you use, there’s 1 core practice I think every team should use: estimation and tracking. It’s a trivial exercise which can yield substantial results. It isn’t a silver bullet, but in my experience it easily outweighs all other procedures. It works equally well for small or large teams and should take less than 10 minutes a day.


What do you need to do?
The first thing you need to do is break-down tasks and assign them to people. The next thing you need to do is put an estimate, in hours or days, on each task. This can either be done together by the team (preferred) or you can let each developer estimate his or her own tasks. Finally you need to update how much time has been spent on each task as you move ahead.


All of these things can be done using a modern bug-tracker. We currently use Redmine (http://www.redmine.org/).


There are a couple things you should do to make this a painless process:



  • Avoid really short (less than 0.5 days) or really long (greater than 5 days) tasks. Short tasks should be grouped up together in a way that makes sense. Long tasks should be broken down. The longer an estimate, the more likely it is to be off. It’s ok to put-off breaking down a task until the work actually starts.

  • Always estimate in ideal time (as though you were working on the task without any interruption).

  • If you are estimating as a group, don’t spend too much time arguing about how long something will take. If everyone is pretty close, stick with the average or majority. If even one person is really off, discuss the task in greater detail. Maybe the hold-outs will point something out that’ll make others adjust their estimates.

  • If you are estimating as a group, don’t let your quiet developers be bullied by your loud developers. Similarly, don’t let junior developers get trumped by senior developers. How you handle this is up to you, but you might try having everyone write the estimate on a piece of paper. You can also count to three and have everyone show fingers, at the same time, for how many days they think it’ll take.

This tiny bit of information is actually quite useful. You can plan on releases based on actual work rather than arbitrary release dates, you can gauge if developers are busy with non-programming tasks and you can hold developers accountable.


Some developers might not like being held accountable. I have mixed feelings about it myself, but deep down I know that there’s no reason why developers shouldn’t be. I don’t mean accountable in the sense that “you go over by 1 hour and you’re fired”. There’s nothing wrong with estimates being wrong, or unexpected difficulties being encountered, or even just not having a good programming days. When such things happen the estimates need to be updated and the team might need to help each other out a little more.


This is a system, and some developers will likely try to game it. To get any value from this, the team needs to meet every day and keep itself in check. Each member must go over what he or she worked on during the previous day. This will help keep individuals honest. You can spend 1 minute per team member, have him or her log his time in front of everyone, and move on.


(I know that many methodologies have very similar, if not exact, practices).

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

19 Responses to The Bare Minimum

  1. faffy fuck says:

    Re: “That isn’t to say that I favor cowboy engineering”.

    Have you ever seen a cowboy in engineering??! The do cows and politics!

  2. AndrewLV says:

    Rob,

    While I am in no way advocating the way I suggested (“real” time estimates), but the reality is, that is often how estimates are made. If something needs to get done by a deadline but the developer who is working on it is constantly pulled off the work, that is a something that needs to be known by someone, or a deadline is going to be missed even though said developer technically had plenty of hours to complete the job.

    Again, I’m not saying it’s right or wrong, just that someone (or something) needs to take account other work activities into timelines.

  3. In a company that makes business decisions based on some level of return on investment, it would be responsible to be able to reliably make estimates and determine some velocity based on those estimates. Story points based on a relative story (i.e. user login) estimated on the fibonacci (planning poker) is probably a best practice. It addresses the issues of performance improvement (as you improve performance, you have a new story point velocity).

    In organizations where something is sold other than just code (i.e. support, implementation, related services) or the organization needs to change its support (marketing, sales, finance), you are going to want a project manager. This is just about every company. The project managers job should not be to micro-manage the developers. They can be self organized and managing once they learn how to make and keep reliable promises about quality and velocity. The project manager should be making sure team is getting everything it needs to be productive during iterations, the rest of the organization is aligned with releases, the financial reporting is complete, etc.

    I think comments like the one that started this post lead to conflict that delays an organization’s ability to deliver value to the customer. It would be far more productive to help everyone get in the appropriate role to improve the flow of value.

  4. Rob says:

    @Bobby, that’s the danger with time based estimates. You should however, definitely not include breaks etc… The estimate should be in “ideal” hours, ie if you could work uninterrupted.

    If you want to track it in more detail, make sure you do detailed task breakdowns for each story and get developers to put that actual hours against each task. That way you can total up how long a story actually took to complete, and compare it with the ideal hours estimate. The tricky part is getting developers to fill it out in the first place, and to be honest!

    @AndrewLV, I find “real” estimates dangerous. As you mention each week may differ, and also for each task it may differ. I’d personally avoid such a calculation as you’re attaching other work activities to how long a task can take.

    I think they should be separate. Going to meetings and having breaks is a part of the job and should be expected.

    The development team should make an agreed commitment prior to planning an iteration, as to how much they can complete. This has to take account of meetings, people being on holiday, breaks etc…

    That’s why I prefer point based estimates. It’s much easier to apply than trying to think of how many hours it will take (which developers more than often get wrong).

    Using the fibonacci is a good way of estimating. 1, 2, 3, 5, 8, 13 etc… It forces developers to pick their estimates better. Also for larger estimates you shouldn’t be concerned with detail. The larger the story, the less accurate you can be, which is why it’s good to break down large stories.

  5. AndrewLV says:

    Bobby, you generally want a developer to estimate how long it would take complete a task as if they could work un-interupted. This way you can figure out what sort of modifier you need to multiply their hours/days by to come up with a “real” estimate.

    For example, let’s say I’m constantly in meetings and getting pulled off projects to go golfing with the executives, in reality it means my 8hr task takes 40 to complete, so in the future, any task that I estimate you can simply multiply it by 5 to get the “real” estimate.

    Of course, this assumes that every week is the same by ways of interuptions and a bunch of other variables that can easily muck up the calculations, but assuming you have enough history with a given developer, it’s better than nothing.

  6. Bobby says:

    One of the things that’s confused me with time based tracking is that developers take a lot of breaks, and can’t be working on each task constantly. Should the estimation include these breaks into each task? Should it be proportionate to how long the task will take?

    There might not be an answer for this, but like I said, it’s why I’ve never really like time estimation

  7. Rob says:

    We have a similar setup, but still have a project manager who watches over two teams. He doesn’t interfere much though apart from when we can’t agree on something or have a problem we can’t decide on ourselves.

    He mainly watches over and maintains Mingle, our web app for managing ideas, storys, bugs, iterations, releases etc…

    One thing we definitely don’t do is time based estimation. The reason for this, is as a developer matures, tasks take you less time. This makes it difficult to measure a teams performance as the goal posts keep moving. Therefore we use point based estimation, but keep a wall of previously estimated stories to compare against when estimating a new story.

    We also use planning poker for estimating a story. We go over the story then when everyone is ready we all draw a card as to how many points we think it’s worth. This stops people being persuaded by others as they can’t see their estimates.

    We include dev and qa as part of the estimate. I often find companies estimate just using dev’s, but testing is part of the commitment and should not be left out. Once a story has been estimated, we note who was present which is handy. I’ve often had to work on a story I’ve not estimated, so it’s good to know who did estimate it so I can talk to them should I need to.

    Like you mentioned we keep large tasks broken down. Typically anything that will take more than 5 days gets broken down further. The smallest story should take us no longer than half a day though, as we don’t want to get too granular.

  8. karl says:

    @Chris:
    Redmine was trivial to install, but that’s likely because we already have mongrel, ruby, rails and mysql installed.

    @SimleM:
    What I’m talking about doesn’t require a project manager – there’s no reason why a team can’t do this itself. If you already have a project manager, then of course this should be a core part of his or her job.

  9. Jim Cooper says:

    I also vote for never using ideal days.

    First off, they’re not a very accurate way to estimate. Estimating time is something almost everyone almost always gets wrong. You can have no confidence in your estimates that way.

    Developers are better at comparing complexity of tasks than estimating time a given task will take.

    Secondly, too many management types just see the number of days, and therefore turn an estimate into a delivery date (and too many of them refuse to be educated differently). That way a world of pain lies.

    Also, doing velocity calculations gets a bit weird if you estimate in ideal days. You get ideal days/week (or similar), which is a tad confusing for some. Correcting estimates also gets confusing with multiple meanings of “day”.

  10. SimleM says:

    But what you are talking about is not some kind of project manager? I think I didn’t completely understand your article.

  11. Chris says:

    How many hours were estimated to get RedMine up and running? It’s ridiculous.

  12. Ian Cooper says:

    I’d recommend Planning Poker as a technique for achieving that style of estimation: http://www.planningpoker.com/detail.html

  13. Steve Py says:

    Every new client I work for I’ve brought up similar points. I break my day into two blocks of 4 hours and estimate in 4 hour blocks. if something’s expected to take less than 4 hours then I group it up with something else or pencil it in for the afternoon when I’m typically side-tracked with other stuff, meetings, etc.

    I have worked in extremes where clients expected every task to be tracked with an estimate and actual recorded against it. Maybe it improves their forecasting but it certainly adds weight/cost to the project.

    Project managers do have some uses though. They’re typically quite good at shielding development teams from the pressure/wrath of management. I’ve worked with some really good ones, but most are ineffective.

  14. karl says:

    Anne Marie:
    Story points are even better than time related estimates, but I wanted to keep this simple.

  15. Anne Marie says:

    Why do you prefer estimating in ideal hours instead of estimating in story points? I find story point estimating better because the estimate will be the same whoever does the work. Different developers might need more or less time in order to solve the same task.

    After some iterations of story point estimating, the team is used to the technique and the scale (which can and will differ from team to team).

  16. karl says:

    Jaime:
    By small tasks I mean those 5minutes – 1 hour things. Maybe create a task called “Refactor Authorization System” – 0.5 days.

  17. I agree that < .5 day scheduling is probably meaningless and wrong (for me, something either takes literally 5 min, or is half a day.... there's never 2 hrs), but I wonder why do you prefer to group small tasks? I tend to prefer small task scheduling, between .5 day and 2 days and always try to break anything >= 5 days

  18. Trevor says:

    I’m not a fan of hours based estimating myself. In the past I’ve tried breaking stories into tasks with hours associated to tasks. Frequently I found that not all the tasks necessary to complete a story were thought of up front, and that testing/user acceptance was never included in the time. So we frequently ended up with the “Well, it’s code complete but just waiting for testing.” statements.

    I’m trying to move my team to a pure story driven project management where we don’t worry about tasks, it’s just -> Is the story done? No. OK, then finish it. If any critical tasks are necessary for a story they can be noted on the card. Stories are sized at the start of the cycle and we include QA in the sizing of the story.

    Our first few tries at doing this have led to a more value focused cycle, and I think is even less project management since we don’t need to estimate time left in the middle of project cycles. .

    Of course, probably what it really comes down to is what is the team comfortable with and that’s what will lead to real success.

  19. Ian says:

    Seems I’m out of a job :)