Using TeamworkPM & agile sprints to get things done

At White Fuse Media we have been exploring ways to introduce elements of agile project management into the way we manage workloads across the company. We recently introduced the idea of a weekly sprint and have found it very helpful so I thought I would share our experiences.

The success of the change is very much due to the functionality of the team collaboration tool we use, Teamwork (you can read our brief review of Teamwork here) though hopefully much of what follows is relevant to users of other systems too.

Hacking the agile methodology

Agile methodology grew up in the software development world and is a lot easier to apply when you are working on one product. At White Fuse Media we tend to have around 20 external projects running at any one time and numerous small internal ones. Using agile methodologies in this context requires some hacking of the pure concepts.

Benefits and shortcoming of using task lists to manage workload


At the heart of our workload management systems is the task list. Most of the popular online collaboration tools are in some way based around projects and tasks. Teamwork is no exception – it has projects, task lists and tasks. Tasks can each have a priority, estimate and due date.

We see task lists as crucial to effective working. By getting tasks out of people’s brains and into an organised structure we leave our brains free for creative thinking. Ideas can be captured for later evaluation and we can prioritise our time effectively. However, over the last year or so we have become aware of the shortcoming of using task lists alone to manage our workload.


First, task lists can quickly become overwhelming. While Teamwork’s priority functionality allows us to focus on the most important tasks it can be daunting to be faced with an unending task list.

Second, it proved very hard to know how much we would get done in any particular week. Each member of the team would work through tasks in their task lists but there was no way of tracking whether it had been a good week or a bad week on the productivity front, except by gut feel.

Third, we struggled to effectively record our time. We see time recording as crucial to check that we are running project to budget but the accuracy of our figures depend on individuals in the team having easy ways to record their time.

Introducing ‘sprints’

Key concepts in agile project management methodology include the breaking down of large tasks into small tasks and assigning each small task a time estimate. A reasonable number of small tasks are then allocated to a person or team over a period of time (a ‘sprint’). The rate at which these tasks are ticked off is measured (the ‘burndown rate’) and this allows the team to get an understanding of how quickly work is being achieved and how accurate estimates are. This information can be extrapolated to get an undertanding of how realistic larger project milestones and deadlines are.

We chose a one week period as our sprint period. Rather than attacking our whole task list each day, we decided to start each week by considering priorities for that week and pulling an achievable number of tasks into a specific task list for the week.

TeamworkPM’s ‘workload’, ‘estimates’ and ‘due dates’ functionality

Although Teamwork is not specifically structured around the agile methodology (there are a whole wealth of systems which are) it has a number of extremely useful features that we used to introduce the agile concept of a sprint into the agency’s company wide processes.


The first step was to start assigning estimates to all of our tasks. This takes some thought since to fit with week long sprints each task must be defined with sufficient granularity to be achieved within a particular week. On the other end of the spectrum, the tasks couldn’t be too small otherwise the admin associated with creating tasks, assigning and estimate and then recording time against them because too arduous.

Due dates

The next step was assigning tasks to the next sprint.

Because we run many projects concurrently for different client it was still very important to track project progress on a per-project basis. This meant we couldn’t actually create a separate task list for the sprint. Instead, we decided to use Teamwork’s due date functionality for this. This requires a slight shift in understanding of ‘due dates’. Due dates become the final day in the next sprint cycle, which is often slightly different to the intuitive purpose of due dates on a task (we have shifted to using ‘milestones’ to track important client deadlines that then inform our sprint priorities).

After we have set a due date for the week’s tasks, we then use the ‘everything’ tab in Teamwork to view all active tasks that are due by the end of the coming week. That is our agenda for the week.

One huge advantage of this approach to task management is that it gives individuals much more control over what tasks they choose to do at any particular time. It doesn’t matter which tasks are done first as long as everything gets done in the week. One caveat to this is that we prioritise tasks which are dependent on other tasks (another brilliant feature of Teamwork).

Workload tracking

The icing on the cake of this new way of working is Teamwork’s ‘workload’ feature. This gives a snapshot of the whole team’s workload for a particular time period. By setting this for the coming week it is possible to get a quick view of how busy the team is and how well everyone is doing with their week’s tasks.

At the end of a successful week this system gives the deep satisfaction of looking at an empty task list!

This is all still very much a work in progress so please share your own experiences below.

  • Rick Dolishny

    What an incredible use of Teamwork. I’ve been assigning start, due and task dependencies but have been missing a way to connect this information. I’m going to be spending some time with workloads for sure and will re-read this blog post a couple of times to get it all. Very well done!

    • Andy P

      Thanks Rick. Please report back any further insights!

      • kevinjgallagher

        How are you tracking points shifted I. Teamworks?

  • Steve Goodman

    Great post! I love the idea of “hacking” a formal methodology to make it fit your own culture and projects. Indeed, why not? At the heart of the general concept of agility is the freedom and flexibility to improvise and innovate.

  • Pingback: Hacking agile marketing methodology: The role of improvisation and()

  • Melanie Richards

    Great article… I too am needed to implement more Agile type management… how is the weekly sprints working out? Thinking of trying this.

    • Andy P

      Thanks Melanie. We’ve been working with this system for a while now and it’s working really well. It feels like we’re pushing the TeamworkPM system quite hard and it creaks at various points but just about holds. One frustration is that the ‘everything’ tab on TeamworkPM doesn’t have a handy ‘this week’ view.

      But in general the idea works well and we now have a much firmer grasp on our workload and capacity.

      If you try it, get back to us on how it goes!

      • Donny Nyamweya

        Hi Andy P. I think that some recent updates to TWPM may have provided the filters needed in the everything view.
        I have been using TWPM for several months, but I am now getting ideas on how to add Agile methodology into my formal workflow. Good article and reactions here!

        • Andy P

          Hi Donny. Yes, those features just been added which is really helpful. Thanks for the positive feedback.

  • Casper

    Interesting article. We are in the same boat. Have you managed to export something what could lead to a burndown chart from teamwork? Would be very helpful on larger projects.

    • Andy P

      Sadly not. In fact over recent months we have found that we are pushing Teamwork too hard with this stuff and started to lose faith somewhat. Particularly disappointing is their unwillingness to put a ‘tasks this week’ view on the ‘everything’ dashboard. This seems so obviously useful and is in every other system I have reviewed and it makes using teamwork to manage a weekly workload frustrating. Also the lack of any workflow in tasks means we are finding ourselves building workflow through dependent tasks which is v time consuming.

      In summary, though the system described here works passably, we are now on the lookout for something slightly more flexible which can facilitate more genuinely agile approaches where necessary. Any ideas welcome.

      • Dawn

        Some good tips – thanks! A tweak that we’ve adopted is to combine the priority flags with the everything dashboard for our working view. For us red=complete today, yellow=complete this week, green=active/keep in sight. We then sort by priority so red is at the top. We still use start and due dates if they are real, but we don’t like false deadlines for handling daily workflow. Not only are the flag colors easy to adjust as circumstances change, but they make it easy to see everyone’s week. We review completed tasks at the end of the day to pick up the next tasks in projects (setting dependencies was too much work). I don’t know if this will be of any use to you, but I thought I’d share just in case.

        Your point of setting estimated times is something we’re still struggling with. I’m going to focus on it this week to see if I can get more consistent with it. You’re also right about dependencies; it’s a great feature that’s too difficult to use. The option to toggle a task list to serial or parallel would be really helpful.

        • Andy P

          Cheers Dawn. I like that clear definition of priority tags. We’ve never used them successfully and I think it’s because we haven’t every agreed a company-wide definition.

          However, one reason why we are tied to using deadlines even if they are a bit fake it that we use Teamwork’s workload function to map out team availability into the future. This only works if you use the due date functionality.

          We’ve actually been tweaking this quite a bit. We are now starting to just use teamwork for larger project tasks like ‘build prototype’ and smaller non-project bits and pieces. We then use Trello to break down and track project development work based around user stories. It’s a work in progress but we are enjoying the direction because Teamwork was getting too unwieldy when we tried to contain project requirements within task lists.

  • Alper Ortac

    Although i did not use it yet, i think that is an alternative and worth a look.