Skip to content

10 Principles of Agile Project Time Management

June 23, 2008 by JurgenAppelo

Timemanagement Project Time Management is one of the nine knowledge areas of the Project Management Body of Knowledge (PMBOK). It deals with the definition of activities (what are we going to do), the sequencing of the activities (in what order are we going to do them), and the development and control of the schedule (when are we going to perform those activities).

Agile Time Management
Over the past couple of weeks I have been trying to find out what the main principles of time management are in the case of agile software development. I was able to distinguish 10 principles so far, and I will present them here for your convenience. With each principle I also include a reference to an online article that (as far as I can tell) nicely describes the ideas behind it. If you don't agree with my list, or if you know some better reference material, feel free to add your thoughts!

1. Use a Definition of "Done"
How? Define what "Done" means and only count the activities that are Done.
Why? Prevent the build-up of hidden tasks ("technical debt") that cost a lot of time to fix down the road.
See: The Definition of "Done"

2. Use Timeboxes to Manage Work
How? Set a start- and end date for a collection of activities, and don't allow changes to those dates.
Why? Timeboxes keep people focused on what's most important. Don't lose time to perfectionism.
See: Time Boxing is an Effective Getting Things Done Strategy

3. Don't Add Slack to Task Estimates
How? Don't use scheduling and buffering of tasks. Add one buffer to the end of the timebox/project.
Why? All safety margins for tasks will be used ("Parkinson's Law" and "Student's Syndrom'").
See: Critical Chain Scheduling and Buffer Management

4. Defer Decisions
How? Make decisions only at the latest responsible time. "No Decision" is also a decision.
Why? The environment may change, making earlier decisions a waste of time.
See: Real Options Underlie Agile Practices

5. Reduce Cycle Time
How? Iterative cycles should be as short as possible.
Why? Speed up the learning feedback loop, and decrease the time-to-market.
See: Lean Software Development: Why reduce cycle-time?

6. Keep the Pipeline Short and Thin
How? Limit the amount of work-in-progress, and the number of people working in sequence.
Why? Improve response times, speed up throughput.
See: Managing the Pipeline

7. Keep the Discipline
How? Prevent expensive rework by doing some processes well, right from the start
Why? Solving problems late in a project is more expensive than following proper rules early.
See: The Power of Process

8. Limit Task Switching
How? Prevent unnecessary task switching between projects, and prevent interruptions.
Why? Tasks get completed faster on average, and the human brain is bad at task switching.
See: Human Task Switches Considered Harmful

9. Prevent Sustained Overtime
How? Disregard (sustained) overtime as a way to accellerate progress.
Why? Lost productivity, poor quality and bad motivation among team members.
See: The Case Against Overtime

10. Separate Urgency from Importance
How? Urgent tasks and important tasks should not be done at the same time.
Why? The important stuff will usually not get done, costing you more time in the long run.
See: A 10 Second Guide to Smoother Projects: Urgent vs. Important

Comments

repost request

June 23, 2008 by Wei Ling Chen (not verified), 1 year 32 weeks ago
Comment id: 1598

Hi Jurgen,

I've enjoyed reading your blog a lot and would like to talk to you about reposting to our DZone Network. Could you please shoot me a message at weiling@dzone.com.

thanks much!

10 principles of time management

June 24, 2008 by Michael Erwin - Time Management Coach (not verified), 1 year 32 weeks ago
Comment id: 1599

An interesting and well written article. I can understand your points and some of them are excellent such as limit task switching and separate urgent from important. I am not so sure about a couple of the others. Based on my experience in the software industry and now as a time management coach I am not convinced about "don't add a buffer to time estimates" and "defer decisions". I have found my clients (and my previously staff) are very bad at estimating how long task will take and they always under estimate, so a buffer was important in managing expectations. Also, deferring decision falls in to the area of procrastination and can lead to people avoiding making decisions. I'd be interested in other thoughts on this.

Really a great article

June 24, 2008 by hmoeller, 1 year 32 weeks ago
Comment id: 1600

In fact, the best one of yours I've seen so far. Congrats. I will bookmark this and I'm already looking forward to reading all those well chosen references. Thanks.

Deferring decision

June 24, 2008 by pbielicki, 1 year 32 weeks ago
Comment id: 1601

Michael I think you've got a point here and I agree with you. Especially "defer decisions" is not the best way to do any projects - "the worst decision is lack of decision". If you made the wrong decision it's OK - you have to accept risk and learn on your mistakes. If you don't make decision how can you gain anything?

About the buffer - I think if you estimate the task you should stick to it without any buffer. If you made mistake you should assume that you are under or overestimating next time. Adapt - it's about agility :)

The latest responsible time

June 24, 2008 by hmoeller, 1 year 32 weeks ago
Comment id: 1603

"Deferring decisions" is about deferring, not avoiding.

Obviously, you have to take decisions when the time for decisions come. This in fact is the latest responsible moment. Any time later is too late.

But if you take decisions earlier than that, chances are that you are discussing matters which don't really come into play at all. And that's simply it: a waste of time.

Give the referenced article a shot. It clears things up, I think.

Deferring decisions

June 24, 2008 by JurgenAppelo, 1 year 32 weeks ago
Comment id: 1606

Guys, thanks for your feedback. I agree with hmoeller on this. I think you should read the article first. You would then understand that "deferring decisions (until the last responsible moment)" is definately not the same as procrastination or avoiding decisions.

Deferring decisions

June 24, 2008 by pbielicki, 1 year 32 weeks ago
Comment id: 1610

I think everyone understands what you mean ;) but you wrote 10 principles and in my opinion principles should be self-explanatory without any space for interpretation. If you can translate principle on many different ways it's dangerous because many people can understand it on many different ways.

BTW. "Deferring decisions" in my opinion clearly derives from XP "simplicity" value i.e. implement what you need today and nothing more. If you need something else tomorrow you will re-factor what you implemented today (or implement it from scratch).

What about re-factoring decisions then? :)

Thanks for that important

June 26, 2008 by Software Development (not verified), 1 year 32 weeks ago
Comment id: 1620

Thanks for that important information, it really helpful..Interesting article

Quite Old List

June 26, 2008 by Michael (not verified), 1 year 32 weeks ago
Comment id: 1622

In fact just 1 and 2 are new and came fro agile, all the other tips are old and well-known. So the word Agile is just a buzzword here.

Old List

June 27, 2008 by JurgenAppelo, 1 year 32 weeks ago
Comment id: 1623

In fact, 1 and 2 are not new and are not agile inventions either. In fact, almost everything that agile preaches already existed before. It's just that everything has been given a much better presentation by the agile folks.

deferring decisions

June 30, 2008 by Ilja Preuß (not verified), 1 year 32 weeks ago
Comment id: 1627

When deferring decisions, I think it's important to do so *actively* - that is, think about "what do I have to do to be able to further defer this decision?" That's very different from procrastination, and strongly linked to the lean Set Based Decision Making - making a decision that keeps your options open.

adding slack

June 30, 2008 by Ilja Preuß (not verified), 1 year 32 weeks ago
Comment id: 1628

It's true that it's very hard to "correctly" estimate stories/tasks. In my opinion, a better way to solve that problem is by estimating in abstract units of time and using "yesterday's weather" to decide how much can be done in an iteration. Or, if you really need real units of time, use a load factor.

"old list"

June 30, 2008 by Ilja Preuß (not verified), 1 year 32 weeks ago
Comment id: 1629

Jurgen, thanks for taking the time to think about time management in an Agile context. If the resulting list is also useful for non-Agile projects, all the better!

What about tracking your time?

July 1, 2008 by John (not verified), 1 year 31 weeks ago
Comment id: 1630

Seems like another important component would be tracking your time. The reason is that tracking your time effectively provides you with invaluable data on how long it takes you to accomplish certain tasks. As you continue along in your cycle you will start to see similar tasks repeating themselves and will be better able to slot them into your workday knowing how long they will take. We've been doing this for years and have found ourselves transitioning much easier into agile development as a result. Thanks for the list!

Tracking progress

July 1, 2008 by hmoeller, 1 year 31 weeks ago
Comment id: 1631

@John:

I don't fully agree with you about time tracking. It strongly depends on each individual developer's attitudes whether she finds time tracking useful or rather considers it as kind of spying on her. But if you follow Ilja's hint and use abstract time units (e.g. Story Points) for estimation, you can track progress without spying on your developers. And in the end, this has at least the same effect when it comes to estimating repeating tasks better over time.

What I fully agree about is the importance of historical data, though.

Project Time Management

March 3, 2009 by Bong (not verified), 49 weeks 14 hours ago
Comment id: 2318

Hi, I think this article is very interesting however I have been trying to look if there are specific standards when it come to the allotment of "time" when it comes to project management. I mean how many hours should we be investing in actual project management for a particular deliverable? Is there a rule like 10% of actual project effort?

Thanks...

Contradiction between "define done" and "timebox tasks" ?

June 28, 2009 by SridharVanka (not verified), 32 weeks 2 days ago
Comment id: 2779

I am not sure if I got it right, but there seems to be a contradiction between
1. Use a Definition of "Done" ; and 2. Use Timeboxes to Manage Work
My understanding is that you either you work on a task till it is "done" as per your definition or you work on the task till the time alloted runs out.

Is that the right understanding ?

Project Management

July 28, 2009 by Project Management (not verified), 28 weeks 8 hours ago
Comment id: 2914

Great work on this article... I will definitely share it with my staff at work... Thanx and keep up the good work

how to do

November 22, 2009 by Anonymous (not verified), 11 weeks 2 days ago
Comment id: 4129

Timeboxes keep people focused on what's most important. Don't lose time to perfectionism.
See

The latest possible time

January 20, 2010 by mythical Man-Month (not verified), 2 weeks 6 days ago
Comment id: 5199

I think you should change the this principle to "Based decision on Complete Facts" , what you are accomplishing by delaying the decision making is to get enough knowledge and understanding of the situation to make a sound decision. the problem is identifying when is that the case. your point is the longer you wait the more knowlege you have about the particular situation. So the solutions is to create a systematic approach for facts finding. the solution is to create a test driven approach, start by creating test cases before you do any depelopment, this will force you to think about every "What If.." situation expediting your fact finding period,

BTW. "Deferring decisions" in

February 6, 2010 by e okul (not verified), 3 days 4 hours ago
Comment id: 5456

BTW. "Deferring decisions" in my opinion clearly derives from XP "simplicity" value i.e. implement what you need today and nothing more. If you need something else tomorrow you will re-factor what you implemented today (or implement it from scratch).

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <b> <i> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <img> <br> <blockquote>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>. Beside the tag style "<foo>" it is also possible to use "[foo]".

More information about formatting options

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
Image CAPTCHA
Enter the characters (without spaces) shown in the image.

Best of AgileSoftwareDevelopment.com