Select Page


Planning and Budgeting in Scrum Projects
By Jeroen Keppens

In a pure waterfall project, processes for planning and budgeting are well defined. Scrum on the other hand provides a very flexible way of development which might make planning and budgeting more difficult.

When you start a new project, the Product Owner will need to collect requirements from the customer. Based on the customer brief and requirements the Product Owner creates user stories and adds them to the backlog.

Together with the team, the Product Owner can then do high level estimations. These estimations are not time estimations, but complexity estimations.

Story Points

The team will discuss each user story and compare it to similar work done in the past. If you need to make a specific admin module, you compare it’s complexity to another admin module you created. If you need to make a report, you compare it’s complexity to another report you created. You assigned story points to the work done before and can use this information to calculate the story points for the new features. It is important that each team member has an idea of the weight of a story point.

Determining the number of story points is usually done using planning poker. Each team member gets planning poker cards and draws a card with the number of story points they estimate. When you have a lot of different cards, you discuss in the team to see why some people think it’s more or less complex. After the discussion you draw cards again until you come to a value everyone can agree to.

Assigning story points works quite good in well established teams, since they have the same references to fall back on. When a new team member gets on board, it might be good to sketch him the references for every user story (we did this in the past, it had such and such features and it was about x story points). They can then estimate the new feature against the explained references.

When starting a new project with a completely new team, you might want to set your point of reference on one of the mid size user stories. You give it a value of 10 for instance so other stories can be estimated higher or lower.

A quick example: the team knows that developing a “basic admin management module” takes 10 story points. A “user admin management module” is about twice as complex, so they estimate that it takes around 20 story points to develop.

When the team has gone over all user stories, the Product Owner ends up with a backlog with all stories and their story points. He can then prioritize the list to make it complete:


Story Points
10 As an administrator, I can manage users and groups 10
20 As an editor, I can manage articles 5
30 As a reporter, I can write articles 2


In scrum you plan one sprint at a time. The ideal time frame for a sprint is 4 weeks, but you can have smaller or longer sprints if needed. When you want to start planning your sprint, you need to have a rough idea of the availability of your team. Once you know this, you can calculate the number of story points the team will be able to complete during the sprint. This is calculated using the velocity, a representation of the number of story points a team can do.

A quick example: If you have a 5 men team, you could say that you have 4 weeks x 5 days x 5 people = 100 work days available to work on the sprint. But that doesn’t cut it. You need to know how much of that time the team members will actually be able to work on the project:

  • Sprint demo and sprint planning meetings take 4h each. That’s 5 days in total.
  • 2 team members have a couple of days vacation, totaling 8 days
  • 2 seniors will need to do some analysis for next sprint, you estimate 1 day for meetings.

Taking all this into account, you have 86 days of 8 hours at your disposal. BUT this only happens in an ideal world… in reality a developer is not focused on production the whole day. He needs to read/reply to mails, use the bathroom, work on unplanned bugfixes, join the occasional meeting, he can have a sickday, etc… To take all of this into account, we use the focus factor. At the projects I’ve work with, these were around 70%. Depending on your experiences, you could have a higher or lower focus factor per team member. In our example this means that we 70% of 86 days or 60 production days at our disposal.

We saw before that we abstracted time by making estimations using story points. For planning we need to map these story points on the sprint and see what work we can commit to. When you are doing your second or later sprint, it’s not that difficult. You take a look at how much work was done the last sprint and calculate the velocity. The number of story points divided by the number of production days, gives you the number of story points you can produce per day. If you multiply this by the number of production days during your new sprint, you get the number of story points you can commit yourself to.

A quick example: Your last sprint had 75 days and the team completed 25 story points. Your velocity is then 1/3. If your new sprint has 60 production days, this means you can work on 60 * 1/3 or 20 story points.

If you have a new team and a new project, you can use the initially timed story point as a reference (half a day in our example).

The Product Owner can then decide, based on the available story points and his prioritized backlog, what stories will be developed the next sprint. At the beginning of the sprint, the Product Owner and Team will hold a sprint meeting where they discuss the work that needs to be done. The way we work is to have 2 sprint meetings, one functional and one technical sprint meeting. The Product Owner is only present in the first meeting and all functional topics are discussed during that meeting. During the technical sprint meeting, the team will do an initial analysis, split up the stories in tasks and do timed estimations. If the team sees that there is room for extra features, the Scrum Master will inform the Product Owner that he can add an extra story to the sprint. In the opposite case, the Product Owner will choose which story he likes to be removed or replaced from the sprint. It’s my experience that this doesn’t happen often. Usually you see some differences in the estimations, but it evens out across all stories.


Budgetwise it’s not that hard to calculate a rough price. If you know your team’s velocity based on previous projects and you know the total number of story points for the project, you can quite easily calculate the team budget. In our previous example we had 2 sprints totaling 45 story points and a velocity of 1/3. This means our team budget is the number of days (45 / (1/3) = 135) times the cost of a team member per scrum workday.

Cost per team member per scrum day

Start by looking up the number of work days in a year. This is typically 52 * 5 = 260 minus a couple of days:

Weekdays 260
Vacation -20
Holidays -15
Training/Conferences -8
Contingency (sick days, etc…) -2
Total 215
Scrum Working Days 215 * 70% = 150

If you know that you don’t have work for your employees the year round, take this into account!

You then need to look at the total cost to company for the employee. This is what the person costs the company all inclusive per year. You divide this by the number of scrum working days and you know the price per scrum day for a person. If you have a 5 men team, you can calculate the price for all of them and take an average. You add some extra bucks to this day price so it’s nice and round and there you go.

Typically you would then add overhead costs, profit margin, hardware costs, etc… to come to your final budget.

Another way you could look at it, is see what each production unit (a.k.a. developer / designer / etc) needs to earn to make the company run break even. Let’s say that you have 10 employees of which 6 working on production, you would take the total running cost of the company and divide it by (6 * #working days). This gives you the minimum price per employee to have your company run break even. Add your profit margin on top of this and you have a price per employee that includes your overhead cost.

Change Requests

Sometimes the client wants to change requirements. Since the Product Owner is in charge of the Backlog, he’s also responsible for the change requests. The change request and it’s impact on the backlog are calculated into story points:

  • Implementing the change

    For new features or changes on code already developed or in development, you calculate how complex the feature is and compare to the state of the system at the end of this sprint.

  • Impact on backlog

    Changes can make other features on the backlog obsolete or more complex. If another backlog item gets obsolete, you add negative story points. If it becomes more complex, you add story points.

  • Impact on other change requests

    Also take into account that other change requests might be affected by this change request. They might become more complex or easier. It’s worth communicating this in your proposal.

  • Totaling

    Based on both, you come to a number of story points. Example:

    • New feature: visitors can add articles via website, SP 4
    • Impacts on backlog:
      • Visitors ACL, SP +1

This would mean that to implement this feature you will need to add 5 SP to your backlog. You can then calculate the extra budget for this feature or give the client the chance to remove 5 SP from the backlog if he wants to stick to the budget.


So, I hope this gave you a nice introduction on how to do planning and budgetting with SCRUM. At first story points might not sound like a very intuitive thing, but once you get the hang of them it becomes easier each sprint. If you have any extra thoughts on this subject, please let me know via comments!

Jeroen Keppens is a freelance IT & Management Consultant and owner of Amazium bvba (BE EU). He has been using Scrum for 4 years and has experienced the advantages first hand. He often writes on various technical topics (including Scrum) on his blog

© 2010 Jeroen Keppens –

Recommended PM App

Recommended PM App