Mind your estimates

Facebooktwitterredditpinterestlinkedintumblrmail
Planning poker
Planning poker

Estimating your project is the key to figure out how many resources a project needs in order to complete successfully. But estimates are also the key to measure whether everything goes as planned.

The estimate will give the steering committee or a potential client the ability to judge whether a project is worth implementing or not. In addition, if estimates are given to specific user demands (aka userstories), then the product owner/client/customer can make a judgment of whether a specific demand will give enough value to justify the expenses.

Doing estimates, both rough in the start of a project and detailed estimates later on, will give the ability to prove that the project is doing progress, if your estimates are over or under your budgets, if your deadline and milestones can be meet and so forth. There are various ways of doing this and numerous tools that can help you do it.

How to estimate?
There are two ways that I find especially useful when estimating tasks. One is by using hours and days and the other is by using points and complexity.

If estimates are done in hours or days, then the team members probably will have to breakdown the task and give their estimate on the tasks by telling the SCRUM master or project manager how many hours they would need to complete a subtask. Then adding up all the estimates will give the estimate for the entire userstory and then the estimate for the entire project.

However, breaking down every userstory before being able to give an estimate for an entire project might in some cases be too big a task to make sense (you don’t wanna spent weeks estimating a project that the customer don’t want you to do. In that case you can estimate the userstories by given them points or by rating their complexity. Once that is done, you can breakdown and estimate 2 – 4 userstories in each category, find the average time estimated for a complexity and then sum them all up.

An example.
You have 500 userstories in your project. You go through each userstory and give them points on the following in scale

  • 0 Points (No work needed)
  • 5 points (Being the simplest)
  • 20 points
  • 50 points
  • 100 points
  • Over 100 points

Once that is done, you will need to pick 4 userstories from each scale, break them down and estimate them thoroughly. Afterwards you will need to find the average of the estimates given for each scale and then multiply that amount of hours by the number of userstories in that complexity category. Once that is done, you can add up all the hours from each scale and you will have a descent idea about the resources you will need in order to finish your project.

Always follow up
You should always follow up on your estimates to see if they hold – Usually they do not, so beware of this. When you can see a trend in your estimates, you should try to figure out how much they deviate, and make sure to adjust the estimates for the rest of the backlog.

Once you do recognize that your estimates are off, you should recalculate the entire budget for the project. E.g. If all the tasks you complete has a 30% higher use of hours spent than what they was estimated for, then you should adjust your estimates accordingly by adding 30% to the remaining backlog, and then make sure to report your new budget to your steering committee and/or product owner and customer.

Roles and responsibility

Facebooktwitterredditpinterestlinkedintumblrmail

the-broken-chain1Knowing who is who in your project is alpha and omega when communicating to your stakeholders, but more important is to know who is responsible for what – Call it your chain of command if you like, or who to turn to when things start to turn bad.

Below you will find a short description of the 4 roles, that is the minimum you need to assign to your project. There might be other roles and responsibilities that you need to assign, but the four roles below should always be assigned.

Project owner
So what roles should be assigned in a project. First of you need a project owner, who is financial responsible for the project – This is “The big dog in the kennel”, and he or she will be ultimately responsible for the entire project and its success. This person is the one paying the bills, and therefor he or she can ultimately add more resource to the project and save you if needs, change the scope of the project by removing tasks or maybe even close down your project if expenses are too high.

Project manager
The next in the chain of command is the project manager(s). There can be one or more project managers to a project, e.g. if you are doing a project for a customer, then there can be a project manager at the supplier and at the customer. The project manager(s) are responsible for the day-to-day management of the project, and they report directly to the project owner and the other stakeholders, including the steering committee. Reporting can include things like finances, progress, risks, deadlines and other issues – Basically what the steering committee and the Project owner needs in order to make the right decisions.

Product owner
The product owner is responsible for creating and updating the project backlog (which is the list of tasks that sums up your project). The product owner need to know his/hers product well enough to prioritize, update and maybe even remove items from the backlog. He or she is also responsible for creating the sprint backlog, which focuses on the tasks that is to be included in the sprint at hand and the upcoming sprints (see previous blog post on the Product owners rule in scrum projects).

Scrum master
A project (if agile) can have one or more Scrum Masters. The Scrum Masters role is to make sure that the day-to-day progress of the project is running smoothly. This role is normally given to one of the senior developers on each development team. It is the SCRUM master obligation to report any problems that the team can handle to the project manager and product owner, but also he or she needs to make sure that the development runs smoothly on the day-to-day basis.

Resources
The resources that you need varies from project to project. Since this website focuses on IT projects, then you will probably one or more developers or technically personalities, but resources can also be designers, architects, legal advise, security, machinery, buildings, servers and so forth.

It really depends on the project at hand, however there should be no doubt, when it comes to day to day business then the resources needs to know what they are supposed to build, not how to build it, in what order to build it and so forth. If you are a project owner, project manager, product owner or the scrum master, it is extremely important that you focuses on facilitating the project, support the resources and make sure that everybody is moving in the right direction.