The principles of Agile project management took root in the software development and engineering fields. There are many different methodologies (such as Scrum or Kanban) on how to implement these processes, but agile does not have to be complicated and can be applied to any field (but maybe shouldn’t be).

This article aims to take you a few steps beyond the simple principles of Agile, with actionable information, while avoiding the dogma of any particular methodology.

If you want to know how Agile project management differs from traditional project management, this article is for you. Since we are a software company that sells a project management application, I will conclude the article with how OneDesk can help you achieve the things we discuss.

The Spectrum of Project Planning

Projects are essentially end goals that are broken down into the steps needed to get to those goals. Project management is creating those steps, organizing them, performing them, and tracking their progress. Bigger projects require bigger teams – and therefore planning, estimating, assigning, tracking, and coordinating, is frequently a full-time job.

As you can imagine, not all projects are created equal. A simple recipe may suffice when making supper but that won’t work for designing a bridge. The project management methods needed vary radically across this spectrum, and so do the tools.

For most of us, the projects we do at work fall somewhere in the middle of the spectrum:

  • We work in a team and different people will be doing different parts of the project
  • We need to pay attention to the order of our tasks
  • We should have a reasonable estimate of how long it will take us, and when it will be finished
  • For some of us, costs need to be accounted for
  • We need to be able to see if we are on track and how far along we are in the project.


    If this sounds like the kind of projects you work on, with maybe one or two additional concerns, then your work MAY be able to benefit from an agile approach or MAY NOT. Even within these medium-sized projects, there are degrees of how much a project needs to be planned and managed. At the lighter end, a to-do list written on a white board may work. At the heavier end, time-lines, gantt-charts, and resource calendars may be necessary.

    The trick is to find the point on the spectrum where managing your project doesn’t cost more than it benefits. It can be hard point to find.

    Traditional Project Management

    There’s no fixed definition of traditional project management, but for the purposes of this article we will describe some practices that are often followed.

    With more traditional project management, before projects are launched they are thoroughly planned. This means that:

  • As many tasks as possible are identified.
  • Estimations in terms of work/duration are made for these tasks.
  • Costs are also estimated.
  • Assignments are made between tasks and resources.
  • A date that the project will be completed is estimated.


    As you can see, this approach is planning-heavy and requires a lot of upfront work before the project even begins. While this approach may be needed for some projects, it may burden you with unnecessary overhead for many other projects.

    Agile project management rejects this planning-heavy approach, often replacing it with alternative techniques and tools. Three of these techniques are agile points, iterations/time-boxing, and status boards.

    Agile Points

    Agile points (story points) are effort estimates. While traditional project management usually estimates task effort in terms of man-hours, with agile you simply score a task on a points-scale (eg: 1 to 5) and leave it at that. Since this type of estimate takes very little time to make, you are trading lower overhead planning for less accuracy in the estimate.

    A total number of points (or points capacity) is assigned to a project or iteration. We just fill up the project with tasks, until its points capacity is reached. Since some tasks will be over-estimated and others under-estimated, we are hoping it will average out to about right. Experience will tell us how many points our team can accomplish in a given time-period.

    Time-boxing when doing iterations

    Iterations are small projects or the sub-divisions of projects. Time-boxing is the concept of keeping your iterations always the same duration. For example you could break down your 2-month project into four 2-week iterations. You can release or not between iterations. Tasks that aren’t completed in an iteration are pushed to the next. Over time you get better at estimating what can be accomplished in an iteration.

    Time-boxing is often one of the hardest techniques to apply since many projects, can’t just be cut arbitrarily into fixed periods. As well, pushing tasks to the next iteration means that you will not know how many how many iterations you will have.

    Status Boards

    Status boards while not required by agile, are frequently used in agile projects. In continuing with the philosophy of reducing the overhead of project management, status boards allow someone to just drag and drop their task from one column to the next to update the status of their task. These boards also allow for the easy visualization of where the tasks lie in terms of status for the whole iteration.

    Other techniques

    Here are a few other agile techniques and tools which you can consider using in your projects.
    Daily Stand-up Meetings: These daily meetings are where each team member says what they worked on yesterday, what they plan on accomplishing today, and if they have any blockers. They are held standing up to keep them short.
    Burn-down and velocity charts: Burn-down charts show the reduction of open tasks in the project over time. Velocity charts compare time-boxed iterations to each other to see if what the team can accomplish is improving over time.
    Self-assignment: This is the practice of not assigning the tasks, but letting team members grab the next task for themselves when they are finished with the last.

    How OneDesk helps you do Agile

    OneDesk differs from most project management systems in that it allows you to run a project using your choice of agile methods, traditional methods, or a blend of both. Here’s how.

    Create projects that roll up to portfolios or folders that roll up to projects.



    Switch between card views or hierarchical list easily.



    Use Agile points or man-hours to estimate tasks



    Burn-down charts and velocity charts are baked in (and lots of other charts too).



    Watch a video on where to find the agile features in OneDesk




    OneDesk is specially tuned for those medium-
    sized projects that sometimes need a bit of planning and other times a lot less. OneDesk has the flexibility to allow your team to plan your projects to the level you require to meet your organization’s workflow, while not over-burdening your team with too much over-head. With OneDesk you get all the benefits of Agile project management while still having access to advanced tool that you may sometimes need. Even better, you can switch between modes to combine careful planning with quick, effortless execution.

    Let us know if you have questions.

  • One Comment

    1. Olivia

      According to statistics, 90% of managers in 68 countries believe that cross-cultural management is particularly important and consider this aspect of business to be one of the most difficult to work with. And about 70% of businesses fail because of problems based on serious cultural differences. To avoid problems, it is worth developing cross-cultural competence. I read an interesting article on this topic by Nicolas Krafft L’oreal. What should successful business leaders and top managers be like in the context of globalization? Sociable and flexible!

    Leave a Reply

    Your email address will not be published. Required fields are marked *

    You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>