Use Visionate Academy’s full-project-loadout template to set your entire project up in Clickup with just a few keystrokes! Get backlog management, Risks and Issues, Defect Tracking, Stakeholder management, and Decisions and change log. Suits Agile, Hybrid and Waterfall!
Did you know that Clickup provides a facility that lets user save their setups as templates that can be reusable within their organization, or to the wider community?
Visionate Academy has created a comprehensive Clickup structure making use of the full Clickup hierarchy of space, folder, list and task. Using the template will automatically set up your project in its own separate folder. This template was originally developed for consulting clients and it has now been made available to the public.
The documentation in this blog post is a copy of the README wiki that accompanies the template download.
How to get the template
From your web browser select this link to the template: https://app.clickup.com/template/category/t-90031509458/06113906a1c43d6
You will be taken to this screen
- Select the workspace you want to use
- Change the folder name to match your requirement
- Select the space you want the folder created in
- Select to save a copy of the template to your workspace for easy re-use
- Select Use template
- The folder will be created
The project folder will be set up with all artefacts. You can load as many project folders as you like. We recommend each project you run has a separate folder. But if you are running this as a backlog for a persistent agile team or squad, then you can use a single folder to process all their work.
Please note for all images we are using the Compact/Clean layout. Your menus may look different if you are using a different layout
The Product Backlog
The Product Backlog contains all plannable work that is known to the project
It is the single queue for plannable work, whether the work is generated by customers, business, or IT stakeholders; there are no other queues. (Note: unplanned work is registered in the Bugs and Issues component)
Views
Views are ways to look at the data in the product backlog.
Each view can be customized to show different aspects of the data. The template comes preconfigured with a number of views and you can add more or edit these as you desire.
Preconfigured views are shown in the image below
- Add a feature
- The Prioritization View
- The Management View
- By Module View
- Boards view (4 board views)
- Gantt
Add a feature
This is the default view. You can change the default to a different view by selecting a view, selecting the three dots next to its name, and following the menu path shown.
The “add a feature” view allows anyone (even view-only guests) to add a feature to the backlog. There are a number of required fields for adding a feature.
Note: New features go to the bottom of the backlog until they are prioritized.
The Prioritization View
In this view we work with our key stakeholders to determine the order in which work is prioritized.
The approach used is called Weighted Shortest Job First (WSJF)
This is a data driven approach that allows us to determine the cost of delay for each item by:
- First setting relative values for Business value, Time criticality, and Risk or Opportunity value.
- The system will calculate a number for each task which represent the cost-of-delay in relative terms (CoD)
- Next we set a relative job size for each task. (Job size)
- The system will calculate CoD / Job size to arrive at a WSJF value. The highest values are the shortest path to getting value for the business
- We then manually* move the highest WSJF values to the top of the product backlog in the management view. (Note: Changing them in the prioritization view does not affect the management view)
- *We cannot arrange the list to be automatically sorted by the WSJF value because the field is a calculated field and not available for automated sorting.
In the example below:
- The yellow columns are the calculated fields
- The blue row has the highest business value by far with a final score of 42
- But the green row beats it out because of higher risk/opportunity and higher time criticality leading to a higher CoD and giving a final score of 67, even though both jobs are the same size
So in line with the data driven approach, we must prioritize the green line first, followed by the yellow line
The Management View
This is the engine room of the system.
In this view we see the project deliverables by status
You can configure the display to show what data you wish to see. In the example below we have added subtasks to the parent feature. These sub tasks can be tracked on the baords.
By Module View
This view shows what deliverables pertain to each module.
You can customize the text for each module view to be relevant to your project. (See customizing fields entry in this guide).
These are the pre-configured modules which you can customize.
Boards view (4 board views)
There are four separate boards views, each of which is designed for a different purpose. You can, as always, add or modify these view to suit your needs)
Program – Epics Board view
This board provides a high level overview of your objects and their status.
It is focused on the highest (parent) level and subtasks are not shown
Kanban – All tasks
The Kanban view shows all tasks including subtasks
Scrum-Overview
The Scrum overview board shows only those tasks which meet a filter for the sprint you want to see.
When your current sprint changes, just change the filter. All subtasks are exploded and can be individually moved, so this board view can be used for daily stand-ups and the moving of individual sub tasks.
(Do you wonder why we are not using Click-ups built in scrum functions? See the guide page that covers the rationale “
Scrum- By person
Just like the Scrum overview this board shows only those tasks which meet a filter for the sprint you want to see.
The difference is that the view has swim lanes for each assignee. This can be very useful for daily standup because each team member can see their in-progress and planned tasks, making it easier for them to give their daily report.
When your current sprint changes, just change the filter. All subtasks are exploded and can be individually moved, so this board view can be used for daily stand-ups and the moving of individual sub tasks.
(Do you wonder why we are not using Click-ups built in scrum functions? See the guide page that covers the rationale: Why we are not using Click-up’s build-in Scrum functions)
Gantt
The Gannt view displays the schedule for the project.
As you can see from the image below, if you are running scrum, you can set up clear views of your sprints by marking the dates for planned and in-progress work. If you are not running scrum it operates as a traditional Gantt with higher level deliverables and sub-tasks representing sub-products or activities
Automations
Capture Prior Due date
When the due date changes the Prior Due is set to the former value of the due date.
The purpose of this is just to give one layer for history for dates that change.
Bugs and Issue Tracking
After the product backlog this bugs and issues tracking is probably the place you will spend the most time! Just like the product backlog it has a number of views.
Views
Views are ways to look at the data
Each view can be customized to show different aspects of the data. The template comes preconfigured with a number of views and you can add more or edit these as you desire.
Preconfigured views are shown in the image below
Bug Submission Form
This is the default view. You can change the default to a different view by selecting a view, selecting the three dots next to its name, and following the menu path shown.
The “Bug Submission” view allows anyone (even view-only guests) to add a bug to the register.
There are a number of required fields and the more information added the easier it will flow.
Note: New features go to the bottom of the backlog until they are prioritized.
Reported Bugs View
This is the management view of the bug list, grouped by status.
These are the preconfigured statuses
Status Board
Kanban board view of all bugs
By Module
provides visibility of bugs by module. Useful for identifying fragile areas of the system.
These are the preconfigured modules which you can edit to your own needs.
My Submissions
By default this will show bugs assigned to you and grouped by the person that raised the bug
Automations
Status Changes to ‘Done’
When status changes to ‘done’ then it is reassigned to testing status and the assignees are alerted that it is available for testing
Status Changes to ‘Need Info’
When status changes to ‘Need Info’ then a notification is set to assignees advising need to add more information
Status changes to ‘Not a bug’
When the status changes to ‘Not a Bug’ the item is automatically moved to the product backlog.
Please note that you may need to adjust the name in the automation for this to work after yo have customized your list names.
Interpreting status
Open – means an item is on the backlog. It may have been prioritized but is not under active management yet
Planned – means a prioritized item – when running scrum it can be used to denote that the item forms part of the ‘scrum backlog’, i.e., work which has been committed to for the current sprint.
In Progress – Item is being actively worked on, i.e. a team member is working on it
Review/QA – Item may be under investigation or may be in a standard QA cycle
Done – means that the item is DONE in an engineering or configuration sense. It means that the team believe that the item meets specification and is of releasable quality but it may still need to pass higher level testing (SIT/FST)
Done/Done – means that the item has completed all higher level testing and has been accepted by the stakeholders for release
Released – Item is in production and in use
Interpreting Bug Status
Open – means an bug has been received but not yet assessed
Triage – Bug has been assessed and assigned a priority based on its position in the list
In progress – Bug is actively being worked on
Need Info – More information is required before proceeding further (notification is automated – see automations)
Testing – Bug is believed fixed and is in test phase
Done (Fixed) – Fixed bug has passed testing
Cannot Reproduce – error cannot be duplicated – this is a ‘done’ status
Not a bug – Item is a feature or behaving as expected (movement is automated – moved to the product backlog)
Done/Done – Bug is closed
Stakeholder/Customer Groups
The purpose of this list is to
- provide a stakeholder register for visibility purposes
- provide another way to categorize product backlog and Bug entries, if desired
- provide a location to document communications with stakeholders (comments/emails facility)
Stakeholders can also be categorized by their status in the sales cycle
You can use the entries on this list to manage your stakeholder engagement and communications status, and you can also link to any active backlog items or bugs (links can go both ways)
There are also attributes to cover development and deployment versions of applications. You can adjust the settings of these attributes in the normal way.
Risk management
This facility provides a risk register, a board, a Gannt and a form for raising risks
Raise a risk
The default view when you select this component is the form used to raise a risk.
This form allows anyone, even view-only logins, to raise a risk.
Once raised, the risk is loaded to the
Risk Register
The risk register, with dummy entries, is shown below. It covers a wide range of risk management aspects
Risk qualification
Qualification means to measure probability and impact. 1 is very low, and 5 is very high.
The product of these two values results in a Hazard value.
Qualification is fast, easy, and provides great value.
Any hazard of 15 or over is automatically a risk that needs further attention. Any hazard over 10 should also be assessed to ensure it does not need to be taken under management.
Below 10 risks are normally minor enough that they can be accepted, or parked with minor mitigations in place.
Risk Response
There are a number of globally referenced approaches that apply to response. We have kept it simple but if you want to make it more granular you can do so by making the usual changes to the attribute.
Our simple approach as the following
Accepted – the hazard is low enough just to live with the risk, if it happens, it happens.
Avoided – means the probability or impact of a risk is removed. For example if there is a risk that your key team meaning will take leave in the middle of the project, you could pay them a bonus to defer their leave. Risk avoided.
Transferred – means you have moved the risk onto someone else. for example, if there is a risk that core machinery might break down partway through the project you can take out a policy with a supplier that requires them to swap out machinery within 24 hours of failure. It is now their issue, not yours.
Mitigating – Mitigating means that we are taking measures to actively reduce either the probability or impact of a risk. Using the previous example, a mitigation to reduce probability might be to have a routine check made on all machinery at the end of every work day, with a complete strip down and rebuild every 1000 hours of operation. An impact mitigation could be to reduce the amount of engineering happening in the team and outsource part of it. In this way if a problem occurred with your machinery it would have reduced effect.
Under Contingency – This means you no longer have a risk – you have an issue, the risk has been realized, i.e., it has happened and you now need to activate your contingency plan
Risk Quantification
Quantification means to figure out what it might cost you of the risk occurred (i.e., became a realized risk, also known as an issue), We only need to do this for the most important risks.
Quantification involves money, and is a hard metric. If we want to we can get very complicated at working out quantification amounts.
Once we have a quantification amount worked out, the view will automatically apply the probability measure to derive a contingency amount. The accumulated contingency amounts of all known risks should be added to your project budget.
Contingency Planning
We have already covered contingency amounts under the quantification heading above. The last part of contingency planning is to identify what you will do in the event that your risk is realized. Like quantification, we only need to do this for the most important risks.
Decision and Change Log
Use the Decision and Change logs to record significant events and decisions in your project.
Not only does this make it easier to communicate decisions, but it also makes it easier to refer to them down the track in the event that they get relitigated.
Why we are not using Click-up’s build-in Scrum functions
Click up has a comprehensive Sprints management system – why not use it?
Good question.
In setting up this template we investigated Click-ups built in sprint management system. It has a lot of positives and some drawbacks.
On the positive side it manages the mechanics of setting up sprints well, and it has good reporting.
On the negative side, it is only possible to assign parent level tasks to sprints. There is a workaround but it is clumsy.
With Scrum we have a need to manage multiple levels of deliverables (product) and at the bottom level we must also manage activities. In clickup these all get assigned to tasks, but at different levels
- Parent task (e.g., Epics – product/deliverable level)
- Child task (e.g., Features – sub-product/deliverable)
- Grandchild tasks (e.g. Stories – sub-sub-product / deliverable level)
- and great grandchildren (e.g. Tasks – activity level, and things that you want to move around on a scrum board)
In Clickup you can in fact associate tasks with each other using the ‘linked tasks’ functionality but it is not visual and it is not intuitive. All in all we judged it to be clumsy.
So we have chosen, in our template. to stay with the standard ability to have subtasks (up to seven levels) and by choosing the subtasks option to ‘show subtasks separately from their parents’ we retain the ability to move sub-sub-sub tasks around on the scrum board.
Yes, we lose the option to set the board to ‘the current sprint’, but it is a trade-off and we judge that we retain much more functionality than we lose. We also think it is simpler and easier to learn.
In addition it means we can use the same template whether we want to run traditional (waterfall), hybrid, or agile style projects (Kanban and Scrum).
But if you would like to try your hand at managing sprints using the built-in functions then by all means, have at it.
The image below shows you how to get started.
Applying WSJF prioritization in ClickUp
Weighted Shortest Job First (WSJF) is a valuable tool that we can use to derive data-driven prioritization decisions for our project.
Every project is made up of diverse stakeholders with differing views on prioritization.
Learn how to use Weighted Shortest Job First (WSJF) Prioritization in ClickUp with an efficient and data-driven template for prioritizing diverse project tasks. Achieve optimum value, avoid conflicts, and make well-informed decisions while gaining stakeholder goodwill