Using Teamwork Projects and Weekly Sprints to Get Things Done

Posted May 13, 2016

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.

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.

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:

Task lists can be overwhelming and priority systems are very hard to implement across multiple projects with different project managers pushing their agenda.

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.

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.

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.

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

23 Comments

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.

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 :).

I’ve found that “task boards” (aka. Board View) is a good way to manage project phase development. Create boards for each phase (define, design, build, test, deploy). Creating a “tag trigger” for each column and it will automatically create a tag when you drag the task into a column.

NOTE: if you use tag triggers then all other tags associated with the task will be deleted and replaced with the trigger so keep that in mind when using triggers. Otherwise, you can manually change the tags.

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.

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) 🙂

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.

How do you manage features and user stories in team work? Currently we have backlog of features where each features has it’s own backlog of user stories. Then in each sprint, we place what user stories the team will be working on, then on each user stories, we have a list of tasks.

So I wonder how do you manage/keep track of features, user stories, and tasks?

I’d suggest using a Task List named “User Stories” and another for “Features”, then within each list a TASK is used for each User Story or Feature. Using the description tab of each task, the team then include all relevant info on the User or Feature. If the description field is too limited, you could use NOTEBOOK for a detailed description of each User Story or Feature, or even the FILES functionality to hot-link the detailed info within, say a Word Doc, to the User Story or Feature.

With User Stories, create a tag (starting with a sequential ID would also help) for each one so that you can tag each Feature with the relevant User Story name/ID. This allows you to have only one task for each unique feature, but allows you to associate it with multiple User Stories, and see them at a glance in the task details.

I’m fairly new to Agile PM, but I think the ‘new’ Boards functionality (i.e. Kanban) is perfect for managing a team using Agile methodology. We have weekly sprints within a 4-week ‘run’ (a term we’ve coined to suit the agile nomenclature!) Each sprint gets a board (aka ‘column’). We’re currently testing using boards named Week 1, 2, 3 & 4, and tasks get added to the relevant board during each scrum meeting from the Backlog. We also have a board called ‘Upcoming Priorities’ that we add high-priority tasks to that are beyond the 4-week limit to help us see these critical tasks on the horizon. If we consider that we can tackle one of these in the next 4 weeks, the task gets dragged to the relevant column (board). Burn-down isn’t so easy to see (no pretty graph, yet – hint, hint!) but by leaving completed tasks in each board ‘ticked but not archived’ we can gauge the rate by hovering over the board’s top-right corner which displays Total, Active & Completed task numbers.

Hey! This is interesting to read. I myself have experience with the system Podio but recently switched jobs and use Teamwork now (for Support tasks) only. The new company is maybe interested to expand and use Teamwork Projects as well.

I was wondering if ‘Tasks’ are comparable with ‘User stories’ in Teamwork Projects. Also, is it possible to add screenshots in Teamwork Projects Tasks? I would like to create a ‘developmentitem’ for every ‘user story’ in a Sprint. Is this possible in Teamwork Projects?

Thanks for your comment and your interest in Teamwork Projects 🙂 Great to here that you are interested in using Teamwork Projects again!

You can indeed add files to tasks, including screenshots and it is possible to support the workflow you’ve described in Teamwork Projects.

I would definitely recommend you signing up for one of our Introduction to Teamwork Projects Webinars – there you’ll be able to get a good sense of the overall functionality and ask some questions specific to your workflow.

Hi, Is there a how to do video or steps? I come from the JIRA world and trying to setup Scrumban and scrum process with sprints etc. I appreciate this articles helped others, but how to do video or steps would be real helpful.