Benefits in using Timewax for Scrum projects:
- One project accounting system for all projects
- Visual representation of all projects and Sprints
- Resource planning of all projects and other work/absence
- Collaboration on User stories with the Tasks feature
- Reporting on required capacity for each Sprint
- Reporting on Velocity project team (budget vs. actuals)
- Financial processing with the invoicing feature
Scrum will change the way you schedule projects and resources. In this post we will show you how to work with Timewax when you apply Scrum for your projects. Topics that we will cover:
- Project setup
- Story points vs. budget hours
- Tasks
- Scheduling Sprints
- Scheduling employees
- Reporting
- Invoicing
In this post we will assume that you are familiar with typical Scrum expressions like Sprints, User stories and Product backlog. This is how these expressions relate to Timewax expressions:
Scrum expression | Timewax expression | Timewax feature |
Sprint | (Parent) activity | Project |
User story | Activity | Project |
Story points | Budget hours | Project |
Product backlog | (Parent) activity | Project |
Bug | Activity | Project |
Task | Task | Tasks |
1. Project setup
For each project you will create a project in Timewax. In Timewax you can break down a project in activities. Activities can be created in a hierarchy. We will use the hierarchy to define Sprints and User stories. Specifically, for the Product backlog items, we will also create an activity. The entire breakdown structure of a project could be something like this:
Scrum project X
- Product backlog
- User story 01
- User story 03
- User story 06
- User story ....
- Sprint 1
- User Story 02
- User Story 04
- User Story 05
- Sprint 1 resource planning
- Sprint 2
- User Story 07
- User Story 12
- User Story 15
- Bug A
- Sprint 2 resource planning
- Sprint 3
- Sprint .....
Upon the start of the project, all User stories will be part of the Product backlog. This is where all User stories will be defined in more detail and budgeted in number of hours.
When a Sprint is defined, the selected User stories will be moved from the Product backlog to the Sprint. Besides User stories, Sprints can also contain Bugs that have been detected in previous Sprints, and that need to be fixed in the upcoming Sprint.
Each Sprint contains an activity 'Sprint Resource planning'. This is not a Scrum element, but an administrative activity that we will use in each Sprint to schedule employees in the Planning board. Scrum will never schedule employees to the level of User Stories. In Timewax however, we do want to schedule employees to Sprints for reporting purposes. The reporting will enable us to see if we have enough capacity in employees to actually finish the selected User stories.
In setting up the User stories it is important that they are checked for the 'Gantt Chart' and not for 'Resource bookings'. In setting up the administrative activity for resource planning, you need to set this up exactly the other way round.
2. Story points vs. budget hours
For planning purposes, Scrum values User stories in Story points. De smallest User story is valued at two points. By applying planning poker, the relative value of all other User stories is determined. A number of User stories will be selected to determine the number of hours that are required to complete them. Based on that information, Story points are valued in number of hours.
In Timewax, you cannot define Story points at the level of each User Story. You can however define the number of hours required to finish the User story with budget hours. According to Scrum, Bugs are not valued with Story points, so the budget hours for Bugs is 0.

3. Tasks


In the Tasks feature you can add your own views. This way you can create different ways of looking at all Tasks at hand, enabling you and your project team to jointly manage all Tasks.
4. Scheduling Sprints
Here is an example.

This example illustrates that the User stories have the same duration as the Sprint itself. Scrum does not want you to schedule individual User stories with a start and end date. The project team is empowered to work on the User stories during the Sprint as they see fit.
You can add colours to the Gantt Chart for example to distinguish completed User stories and Bugs.
5. Scheduling employees
Next to that you will always have the need to register absence like sickness, leave and training. Resource planning with Scrum will increasingly be simplified, but will still be required to manage resource utilization in projects and departments.
In Timewax you can use the Planning board to schedule employees (resources). For an organization working with Scrum, it could look something like this:

You will schedule employees to a Sprint for full weeks, 3 weeks in this example. In this example you will also see that an employee has taken leave (bookings in orange) and is being replaced by another employee.
6. Reporting
The Utilization feature enables you to analyze the utilization of your organization by department/position. Because you schedule employees both to Sprints in projects on one hand and other jobs and absence on the other hand, you will have an accurate view of the entire workload. Sprints have a fixed nature with respect to duration and resourcing, so this will give you a good forecast to available resources in the future. For that matter Scrum provides some peace and quiet to the resource planning in general.
The Queries feature will give you insight into the utilization of your project on a Sprint level. On one hand we have the budget hours for each Sprint based on the User stories. On the other hand, we have scheduled hours of employees to the administrative activity for resource planning. This way you can easily see if you have enough capacity in your team to realize the Users stories selected for the Sprint.
Here is an example of a query defined with the Queries feature.
In this example you can see that Sprint 1 is 108 hours short in order to realize the User stories for that Sprint. Based on this you could decide to select other User stories for this Sprint, or to add more resources to the team. For Sprint 2 you can see that there are 42 hours left based on the number of hours that we require to realize the User stories.
Optionally you can also decide to register the actual spent hours. This can be done at the level of the User stories. This enables you to analyze if the budget hours (based on Story points) for each User story, were adequately estimated. This way you will also be able to see if the Velocity of the project team increases over time.
The concept of timekeeping is not supported by Scrum. That being said, a lot of service providers are still bound to timekeeping, because not all projects are Scrum projects. Other projects often require a traditional registration of actual spent hours to manage the budget and invoice hours based on time and material.
7. Invoicing
Timewax has 3 options to invoice Scrum projects:
- Hours based on time and material (costing)
- User story (fixed price)
- Instalments
It is also possible to have all 3 options in a single project. For example, you can have a project were User stories are invoiced based on fixed price, but where additional User stories are invoiced based on time and material.
In most cases, Scrum projects will be invoiced based on fixed price per User story or in instalments. At the level of the User story you can define a fixed price. The fixed price can be based on the budget hours, that have been derived from the Story points. However, you can define a higher or lower price. That is simply a commercial assessment.
In the screenshot below, you can see how you can define the fixed price for a User story. In this example you can see that we are charging a higher price (17.000) compared to the budget based on Story points (16.000).
As to the timing of the actual invoicing, it is up to you when to generate an invoice and select which User stories should be included. You can decide to invoice when a Sprint has been finished or to invoice up-front. The invoice itself can display each individual User story and amount.
Alternatively, you can decide to invoice the entire project in instalments. In this case you will need to use the Calculations feature. In this feature you can define the project with it's User stories and determine the instalments, as shown in the screenshot below.
You can define the number of instalments, invoice dates and the amounts for each instalment. You can adjust the amounts manually or distribute the amounts based on a percentage for each instalment.
Comments