Tag: Estimation

Mind your estimates

Jan Schwaner
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.

Change management in agile projects

Jan Schwaner
Facebooktwitterredditpinterestlinkedintumblrmail

change-managementEvery now and again I get the question – How will you manage changes in the project, if it is agile? Most of the time I would like to be able to answer ”I don’t, agile means constant changes, and I’ll manage the changes by doing the project in an agile manner”. However life as a project manager isn’t always that easy.

In almost every project of a foreseeable size, you will eventually get to the point where the Steering Committee or your project owner want to know who decided to do a specific thing in the project you are managing. If you do things agile and don’t keep track of your changes, then you probably can’t answer that question – ”Who decided to use a top menu and not the left side menu that we planned to use right from the start”? Try and answer that question after 4 months of agile development with absolutely no change logs.

So how can you handle changes – Well, there are a couple of different ways, but they all involve using a log. If your project is done agile, then chances are that you are using user stories (if not, then you should try it out, it is awesome). If you are using user stories you can add a log to each user story, and simply keep track of what has been decide by whom, when it was decided and why. Then later on you can access that user story in order to answer why the menu was changed.
A word of caution, some SCRUM tools makes it had to access the items that has been completed and approved during your project. Always make sure that you can access old user stories and sprint logs in the SCRUM tool that you use.

A second way to handle this is by doing a good old fashion change log, however you should not do any long description in change management documents, or else you will drown in paperwork. In stead use a simple spreadsheet with at least the following columns:

  • ID number
  • Date for deciding to do the change
  • User story identification number
  • User story title
  • Description of what has been changed and why.
  • Who decided this.
  • What impact is expect to the project if any.

The third way, and that is for the spoiled project managers, is to have your product owner do the change management for you, but basically he or she will probably do it in the same fashion as described above, or else that person will be the one who will be drowning in paperwork.

Estimation and impact on the project
When doing changes to a project, even if it is agile, you should always make sure that the tasks are re-estimated and you need to know exactly what impact the change will have on your project – What seems like a simple twist in a steering committee meeting may have a big impact on the project when you present it to your developers. Therefor, you should never allow a change to be decided/approved/committed before you’ve got a complete overview of the impact AND are able to explain this to the rest of the project group.