Using Teamwork Projects and Weekly Sprints to Get Things Done

Posted   Customer Success Stories

Today, we’re sharing a guest post by Andy Pearson, Managing Director of White Fuse. He is sharing how he and his team use Teamwork Projects in a unique way to cater to their bespoke blend of agile and sprint methodologies in their workload.

At White Fuse, we build websites for charities. We’ve used loads of project management methodologies over the years and one of the most effective has been weekly sprint planning using Teamwork Projects. When you are managing a small team spread thinly across multiple projects that each span several months, with dramatic peaks and troughs of activity, this approach is very powerful.

Using Teamwork Projects and Weekly Sprints to Get Things Done - Beg steal borrow | Teamwork.com High Performance Blog

Beg, steal, and borrow

We’ve stolen from various methodologies. Over the years, the most helpful approach we found for delivering multiple medium-sized web projects simultaneously was a broad rigid structure of milestones and then, within each milestone, a more flexible approach.

We use all terminology loosely, but have found something that works by hacking together some of the old waterfall approaches with agile thinking. We love the lean startup methodology too and this influences our overall company strategy, though we’ve not found it so helpful for day-to-day projects because we aren’t building brand new systems.

What we emerged with is a very structured project timeline with dated milestones from start to end. Each milestone is aligned with a week, and within this week we focus on delivering the best stuff we can for the deadlines scheduled for that week.

Using Teamwork Projects and Weekly Sprints to Get Things Done - Manage workload | Teamwork.com High Performance Blog

The crux of the matter: how to manage workload

We’ve always been sold on the value of having some central system for managing tasks. If you aren’t doing that, you should definitely check out Teamwork Projects and you’ll find loads of ways to build efficiencies into your organisation just by getting all the ideas out into a shared system and organising them well.

However, the big challenge for us has always been managing workload. How do you promise lots of things to lots of clients and then deliver your promise without burning out your team? We’ve never seen overtime as an option. It didn’t fit with our ethos to push this issue on to our staff. So, we had to find a different solution.

There are loads of tools out there for managing schedules, but we found that none of them really worked for us because we don’t allocate the team’s time neatly by half days. We are working on too many projects simultaneously for this to work and it felt overly prescriptive. So, we chose to manage time in Teamwork Projects, but this resulted in some challenges we had to wrestle with:

  1. Task lists can be overwhelming and priority systems are very hard to implement across multiple projects with different project managers pushing their agenda.
  2. It’s hard to know how much you can achieve in a week. True agile methodology deals with this by removing hard promises on what will be delivered, but this didn’t fit well with our approach of speccing things out clearly.
  3. When one project is delayed, it can be hard to evaluate the knock-on impact. When renegotiating the project timeline with the client, it’s important to know that the new milestones don’t stretch the team too thin on any given week.
Using Teamwork Projects and Weekly Sprints to Get Things Done - Introducing Sprints | Teamwork.com High Performance Blog

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 understanding of how realistic larger project milestones and deadlines are.

While much of process doesn’t look like agile development, we grabbed this element to deal with the schedule management challenges we had. 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.

 

Using Teamwork Projects and Weekly Sprints to Get Things Done - Harnessing the power | Teamwork.com High Performance Blog

Harnessing the power of ‘milestones’, ‘estimates’ ‘due dates’, and ‘workload’ in Teamwork

Milestones – our overarching rigid structure

We promise clear delivery dates to our clients. Tracking these through milestones gives us a range of great reports and overviews to see this big picture client focused view.

But how do we manage the scrappy day-to-day challenge of meeting those deadlines? Enter estimates, due dates, and workload.

Estimates

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. Vague tasks were not allowed! On the other end of the spectrum, the tasks couldn’t be too small, otherwise the admin associated with creating tasks, assigning an estimate, and then recording time against them became too arduous.

Due dates

The next step was assigning tasks to the next sprint.

Because we run many projects concurrently for different clients, 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 Projects’ 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 Projects 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 is that we prioritise tasks which are dependent on other tasks (another brilliant feature of Teamwork Projects).

Workload tracking

The icing on the cake of this new way of working is Teamwork Projects’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. We had to push Teamwork Projects hard and it took a lot of thought and experimentation.

 

Hopefully, some of these ideas will help you explore new ways to get more out of your team with Teamwork Projects!

enterprise

Keep your projects on track with Teamwork.com

Streamline. Connect. Collaborate.

One account works for all Teamwork.com apps. Have an account? Sign in here.

11 Comments

Simon Kelly

Very interesting, but it seems like quite a lot of PM overhead each week? I like the idea of using due dates for end of Sprint. We use Milestones to set the due dates and then assign task lists to those due dates so they all line up.

Reply
Therese Cohalan

Hi Simon,

Thanks for writing in and giving us your feedback. Using milestones to set due dates and then assigning task lists to those is cool. If you’d ever be interested in writing a post about how you guys do it, we’d love to hear it. Email blog@teamwork.com to get in touch :).

Kind regards
Therese

Reply
Alessandro Camara

Hi. Thanks for share your experience.

I would like know how can you control the step for development process (coding, test, deploy, etc). How to know at what stage of the process Each task is?

Thanks

Reply
Therese Cohalan

Hi Alessandro,

Thanks for writing in. Glad you liked the post.
We use tags and dependencies to control steps in the development process here at Teamwork.com. Using tags will allow you to categorize tasks as coding, test, deploy etc, and creating dependencies on tasks mean that you can mark tasks as complete only before another task is marked as complete.
I hope this is helpful. Please let us know if you have any more questions.

Kind regards,
Therese

Reply
Richard

First of all, great article! Thanks to the author for posting.

So inspired am I by this that I’m going to try and implement it within my company. We do a mixture of web projects and IT infrastructure. You have touched on this by mentioning your tagging system but my main concern with this way of working is that you lose the categorised structure of the task lists if you work in weekly “sprinted” milestones, something I think that in a year or so when we look back might confuse us as to how we worked through the project in a methodical way (in stages).

Is this just the compromise when working like this or are the tags more powerful than I give them credit for?

Would there be any advantage in allowing more than one milestone per task list so you could add the weekly milestones in but keep the categorised layout? – or would this adversely affect other aspects of the project?

Thanks again for the article! So much useful content on here, making my job a lot easier (making me look good to my Directors) 🙂

Rich

Reply
Leanne King

Hi Shaun,

I’m not a 100% sure what you mean when you say product backlog. It sounds like task lists and tasks would better serve you but I’d need more information on what you’re trying to achieve?

Leanne

Reply
amey

great insight into sprinting with Teamwork Projects.

I was trying to understand better one aspect in your workflow.
Do you maintain a task-list per sprint ?
Do you have N sprints as milestones ?
or
just a sprint-current and sprint-next as milestones ?

Reply
Leanne King

Hi Amey,

Thanks for reading and taking the time to comment.

For us, we use a task list per sprint 🙂

Hope this helps!

Leanne

Reply
Georgio Menezes

Hi,

I just started using teamwork and have been trying hard to customize teamwork to suit the agile methodologies. The above article has been very helpful in the process.

I wish there was a video to demonstrate it. It would really help out a lot of people who are trying to achieve the same.

It would be great if there was a way to generate graphs for the individual task list rather than the entire project. The reason behind this is I want to track tasks completed for that sprint/week.

Thanks

Reply
Leanne King

Hi Georgio,

Thanks for reading and taking the time to comment.

I’m glad the article was helpful:) I can suggest creating videos for this.

I’ll also share your suggestions with the development team here. I should point out that we will never be 100% agile as we do like the level of flexibility the app offers – it’s something our users love about Teamwork Projects.

Leanne

Reply

Leave a Reply

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