The added value of a planning tool in Scrum.
These days Scrum has become essential for software development. Scrum is a successful method, and it has fundamentally changed organizing projects. Scrum 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 because, with Scrum, you assign people dedicated and as a full-time resource to a project. You place all responsibilities on the lowest level, which means with the project team. Only a minimum of measuring instruments and reporting are in place. A lot of information gets exchanged in an “analogue” fashion via stand-ups. Next to that, you record progress on physical boards.
Does this mean a planning tool will not offer any added value? No, it does not. A budget and planning is still the basis of every project, and with Scrum, it’s no different. A planning tool can also help with 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. With this comparison, you can learn from the past.
1. Scrum does require planning, only in a different way.
Estimating User Stories
During Scrum, you estimate user stories 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 relative to one another via a technique called Planning Poker. All of this results in a broad set of User Stories (collectively called the Product Backlog), all of which have their 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 period, for instance, is 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 five to nine employees. You set up a team 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. You set the target date automatically with the help of 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’re done with the detailed planning of your project, the project time-lines would start shifting. This shifting is awful as other projects are also making use of your resources. As a result, 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 full time on a project. That makes it a lot easier to schedule, 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 needs to work on a different (non-Scrum) project, or they are required to perform operational activities. This shifting between projects needs to be part of the planning to make sure that you can consider absence.
Once the end of the project nears, employees will start to get assigned to other projects. You want to have a clear insight into this process, so you can side-steer when the project ends up requiring more time. It would be troublesome if you 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 always burn through the same amount of User Points per Sprint. Having insight into the capacity planning allows you to consider absence. You plan for fewer 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.
To measure progress and provide the steering, Scrum employs a Burn-down Chart. This Chart shows the hours/Story Points in time, ideally showing linear progress. You plot the actual development against the hours/Story Points that still need to be realized. When measuring the progress on moment X, you only consider the work your team needs to do from moment X to the end of the Sprint. 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 think that they need to “answer for what they did during the Sprint”—justifying stimulate unwanted behaviour. Which makes sense.
However, by registering the number of hours spend on a User Story, will allow you to make a realistic comparison with the User Story estimation. Comparing User Stories will teach you how accurate your estimate was. This knowledge is of great value 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 insight allows management to focus on projects that they should be keeping an eye on.
You measure the performance of a Scrum team as follows: According to Scrum, you should keep a properly functioning team together so they can 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 historical data, it forms a great tool to provide you with this information.
Conclusion
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 added value. You are dealing with a larger pool of employees who continuously move from one project to the next. If you don’t control the capacity planning, the feasibility of projects might get threatened.
We’ve developed our 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.
