Contact Info
198 West 21th Street, Suite 721
New York, NY 10010
+88 (0) 101 0000 000
Follow Us
A photo of a planning done with sticky notes

Scrum: no more need for a planning tool?

The added value of a planning tool in Scrum.

These days Scrum has become essential for software development. Scrum is a successful method, which fundamentally changes the way projects are organized. The method does not employ any traditional ways of budgeting planning or reporting on project progress. So will a planning tool offer added value within Scrum projects? In this blog we are going to find out.

Planning during a Scrum project might seem meaningless, as people are assigned as dedicated and full-time resources to a project. All responsibilities are placed on the lowest level, which means with the project team, and only a minimum of measuring instruments and reporting are in place. A lot of information gets exchanged in an “analogue” fashion via stand-ups and progress is recorded on physical boards.

Does this mean a planning tool will not offer any added value? No, it does not. The basis of every project is still made up out of a budget and a planning. Scrum is no different. A planning tool can also help with an integral capacity planning, across all projects and activities. A planning tool offers a great way to measure performance, and allows for a comparison with other projects. This comparison can then be used to learn from the past.


1. Scrum does require planning, only in a different way

Estimating User Stories

During Scrum, user stories are estimated in Story Points instead of hours. However, there is still a number in hours which is represented by a Story Point. All User Stories are estimated relatively to one another. This is achieved via a technique called Planning Poker. All of this results in a large set of User Stories (collectively called the Product Backlog), all of which have their own estimation.

Determining the lead-time based on Sprints

Once estimating is done, Sprints get planned. A Sprint is a fixed period of a couple of weeks. The time period could for instance, be set at three weeks. The length of a Sprint and the number of Sprints will strongly depend on the size of the User Stories, measured in Story Points (hours) and the available capacity within the project team. If on average the User Stories consist of a high number of Story Points , then a longer Sprint might be required.

Setting up the team (capacity)

A Scrum team consists of 5 to 9 employees. The team is setup based on the required knowledge and skills, but also on the required capacity and the deadline. Are you facing a fixed deadline? Then you can use the number of User Points to determine exactly how much capacity per week/Sprint you need.

Is no specific deadline set for the project? Then you determine the ideal team size and the deadline is automatically determined by the number of Sprints, required by the project team to finalize all the User Stories.


2. Resource planning remains crucial

Making use of a planning within Scrum is easy

Resource planning has always been the Achilles heel of project planning. The moment you were done with the detail planning of your project , the project time-lines would start shifting. This was awful as other projects were also making use of your resources. The resource planning crumbles like a house of cards.

When it comes to resource planning, Scrum is truly a blessing as it aims to have employees working dedicated on a project. That makes it a lot easier to create a planning, as you will be able to assign your employees to a project for a couple of months. That allows the planning to stabilize and reduces the project dynamics. There are still two points of attention: work on other projects and other forms of absence.

Working on other projects

Having employees work full-time on a project is ideal, but not always feasible. In practice, you might find that an employee really needs to work on a different (non-Scrum) project, or they are required to perform operational activities. This needs to be part of the planning, to make sure that you can take absence into consideration.

Once the end of the project nears, employees will start to get assigned to other projects. You want to have clear insight into this process, to be sure that you are able to side-steer when the project ends up requiring more time. It would be troublesome, if you would make promises towards a client and end up not fulfilling them, just because members of the project team are assigned to different projects.

Other reasons for absence

Whether or not they are working on a project or not, employees will still take holidays, get sick or take a course. All of these activities can have quite an impact on a Sprint. You cannot assume that the team will burn through the same amount of User Points per Sprint. Having insight to the capacity planning, allows you to take absence into consideration. You simply plan for less User Points or you get people to replace those absent, allowing you to continue with full force.


3. Measuring performance: the key to learning

Scrum only looks towards the future

In order to measure progress and provide steering, Scrum employs a Burn-down Chart. This Chart shows the hours/Story Points in time, ideally showing linear progress. The actual progress is plotted against the hours/Story Points that still need to be realized. When measuring the progress on moment X, only the work that still needs to be done from moment X to the end of the Sprint is considered. So is there no value in past results?

Time-writing is dead, long live time-writing!

Time-writing is not part of Scrum. Time-writing is looking back at the past and that is not what Scrum is about. They feel this causes the employees to get into the wrong mindset, as they will feel that they need to “answer for what they did during the Sprint”. This would stimulate unwanted behavior. Which makes sense.

However, by registering the amount of hours spend on a User Story, will allow you to make a realistic comparison with the User Story estimation. This will teach you how accurate your estimation was. This is valuable as it allows us to learn from past experiences. Measuring equals knowing, and we will be able to provide more accurate estimations for future projects and User Stories.

Reporting across projects

A planning tool can also give you valid insights into the total project portfolio. Which projects are running smoothly and which projects are facing issues? This allows management to focus on projects that they should be keeping an eye on.

The performance of a Scrum team is measured as follows: According to Scrum a properly functioning team will be kept together to work on future projects. However, we also want to measure the performance based on data. Is the team performance degrading or improving? In scrum terms: is the Velocity of the project team increasing? As a planning tool tracks historic data, it forms a great tool to provide you with this information.



If you only have one team which uses the Scrum methodology, then a planning tool offers little value. It will always be the same team which will work on projects in sequential order. It’s always a good thing to measure performance, but a planning tool will not be a necessity

However, a service provider which employs multiple Scrum teams and also has employees who work on other (traditional) projects and tasks , then a planning tool can offer actual added value. You are dealing with a larger pool of employees who continuously move from one project to the next. If the capacity planning is not controlled, the feasibility of projects might get threatened.

We have developed our own way of implementing the Scrum method in Timewax. Please read this support article to learn more. In this article we present a step-by-step approach that teaches you how to deal with the setup, estimating, planning and reporting of Scrum projects.

Questions or comments regarding this blog? Contact Timewax.

A photo of Mark de Jong

Mark de Jong

Mark is Sales & Marketing Manager at Timewax. He has a background as a project and resource manager with PricewaterhouseCoopers Management Consultants with expertise in the field of Professional Service Automation (PSA)