This article assumes the reader has an understanding of Agile Development. You can learn about Agile here.
At GPMD, the web agency I work for, our project management tool of choice is Asana. There are lots of reasons why we use Asana, but those reasons will be discussed in a separate blog post. The aim of this article is give you a top level overview of our workflow and how we use Asana to manage our projects.
In Asana, a workspace is place where users can collaborate on projects and tasks. Because each workspace has its own group of users, we tend to create one workspace per client. By restricting each client to their own workspace, we minimise the risk of sensitive information being visible to other clients or any other member of staff.
In order to be consistent with our process and workflow, we ensure that each workspace is set up in the same way.
For new clients, the workspace is created during the client onboarding process. For existing clients with no prior access to Asana, the workspace is created at the start of a project or around a strategic piece of work , like a yearly marketing roadmap.
Our Account Managers are responsible for creating and maintaining the workspace.
The basic workspace is set up with a Backlog & Action Points project. (In asana, projects are there to help organise your team's work into lists of tasks).
Each client has a backlog area (project). Simply put, the backlog is the common place where we maintain a list of ideas and features for client websites.
The Product Owner should maintain the backlog on a regular basis, scoping each task, writing stories if required, providing full details around each task and prioritising these accordingly.
You can learn more about what an agile backlog is and how to maintain one here.
Each client also has a Action Points area. This area is the common place where we keep all non-development related action points.
For example, if the Account or Project Manager needs to write a statement of work, the task to do so would be created and kept in the Action Points project.
When a project has been signed off, one or more sprints will be required to complete the project. In product development, a sprint is a set period of time during which work has to be completed and made ready for review.
We start our sprints with a sprint planning meeting. The objective of this meeting is to review each task and decide which ones to prioritise in the forthcoming sprint. These tasks are then moved from the backlog into the relevant sprintboard project in Asana.
In Asana, each sprint has a predefined layout which consists of the following sections (aka swimlanes):
- To Do - A list of tasks, prioritised accordingly and assigned to a developer or PM
- In Progress - A task currently being worked on by a developer or PM
- In Review (UAT) - A completed task, ready to be reviewed on a staging (testing) environment
- Done - A task which has been tested and approved by the Project owner
Once the sprint proper begins, we openly discuss progress, issues and anything else by leaving comments directly into the comments field of each task.
Because we regularly update our UAT environment (test environment) with tasks that are ready for review, this enables us to have a quick feedback loop with the client and/or product owner!
Once the sprint is done, all completed work is showcased to the client and/or product owner. This is either done face-to-face or through a video conference call (we use Google Hangouts). We set things up as follows:
- We have the Asana project opened in our first web browser
- In another browser we have the frontend of the website on display
- We have a third browser tab opened with the admin of the website (if relevant)
We then literally go through each task one by one (tasks from the Done section in Asana) and discuss the work that was carried out. If the client and the product owner are satisfied with the quality of the work, the task gets ticked-off in asana.
Once the sprint is over, all completed development work ( in the done section) gets merged into a release branch in Github. It's a this point that the work is handed over to our sys-admin whose responsibility is to schedule a release for the work to be deployed to the production environment of our clients website.
Tags are used to give to the tasks additional context or to group similar tasks for easy viewing.
We use tags to:
Prioritise the tasks - When a task is added to the To Do section of a sprint, we prioritise them by adding one of the following prioritisation tags: Must have, Should have, Could have, Won’t have. This follows the MosCoW method of prioritisation.
Must Have - Requirements labeled as MUST are critical to the current Project (or sprint) in order for it to be a success. If even one MUST requirement is not included, the project (or sprint) delivery should be considered a failure!
Should Have - Requirements labeled as SHOULD are important but not necessary for delivery in the current delivery timebox. While SHOULD requirements can be as important as MUST, they are often not as time-critical or there may be another way to satisfy the requirement, so that it can be held back until a future delivery timebox.
Could Have - Requirements labeled as COULD are desirable but not necessary, and could improve user experience or customer satisfaction for little development cost. These will typically be included if time and resources permit.
Won't Have - Requirements labeled as WON'T have been agreed by stakeholders as the least-critical, lowest-payback items, or not appropriate at that time.
- We also use tags to differentiate between a new feature, bug and change request - There are 4 different types of tasks:
- New feature: A new product or functionality that delivers business value
- Enhancement: Is an improvement to existing functionality
- Bug or defect (snagging): A software bug is an error, flaw failure or fault causing a system or program to crash or produce invalid output.
- Change request: The request to change something. The change may be desired to add something to the product (usually an enhancement), or take something away (usually a bug)
Once the scope of work has been agreed, we then schedule an internal estimation session. All developers and the product owner collectively estimate each task one by one. We use the Planning Poker technique for estimating as this enables us to have a biased free opinion from each team member on how long a task should take to complete. You can read more about Planning Poker here.
We estimate tasks in hours and not story points. We do, however, use the Fibonacci method of estimating the hours. The sequence of numbers are: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89. The reason for using the Fibonacci sequence is that it helps to reflect the inherent uncertainty in estimating larger items.
For better visibility, we tend to add the estimate at the beginning of the task i.e [ 6 hrs ] CHECKOUT - fix bug with dropdowns.
We use the Asana / Harvest integration to track time directly from within Asana.
Enabling Harvest time tracking is simple: Go to ACCOUNT SETTINGS > APPS > ACTIVATE ASANA.
Start tracking your time: Once we are ready to start work on a particular task, we click on the timer icon to launch to Harvest App.
Once the Harvest App has launched, select the project and task and start your timer.
To stop the timer, you can either click on the timer icon from within Asana or by logging into your Harvest account from a web browser.
...Right, that's about it for now, hope you found this useful.