The PI constant in software estimation

Already in 1975, Fred Brooks suggested in Mythical Man Month, Fred Brooks that you should triple any developer estimation. And reading blog posts, talking to fellow project managers and stressed IT managers, we all know that this is still valid. At the same time all these project managers and IT managers have a hard time accepting this. But from now on, you can refer to the mathematical formula of estimation. We all know it.

C=d*PI

Project Management Estimation = Software developer’s estimation * PI

Yesterday, we discussed this over lunch and one of the bright developers at TUI Nordic said it was the PI factor which wasn’t considered in project management.

 

 

If we see the problem as the circle we could say that we cover the problem by travelling from one end of the circle to the next. And that is what developers estimate. You could say that they are estimating the diameter.

But when they need to complete the task they have to take the route around the circle. Not only do they have to take a longer trip to reach the other side of the circle, they must also complete the whole circle and that was never in their estimate. You have setting up development environment, merging, build script problems and all that stuff which you never considered. That is the circumference of the task.

You cannot argue PI, can you?

Another round of Microsoft Project Tutorial episodes?

I’ve received a couple of questions lately concerning Microsoft Project, which I haven’t covered in a while, so I’ve decided to write some more posts. I will, as I’ve previously posted, also post an example file for an agile project in Microsoft Project. But what are YOU interested in? Post a comment or e-mail me if you have any specific topics for me to cover.

The mandatory stuff

When I have a story writing workshop or some other brainstorming activity, one important task is of course to learn what is really important. Since I’m in the mental moving from scrum to Kanban, this has become more than important. It is crucial.

So, these are my phases of a story writing seminar:

 

The objective

During this part, we discuss the overall objective of the project. What we’re doing and why. I try not only to explain what the customer wants but I want the team to really make the objective theirs. I want them to form their own Commander’s intent so they not only know what the objective is but also what it’s not. We don’t have time for nice to haves. Most of the time…

 

Brain storming stories

This can be divided into a number of separate parts. If it’s a new group or the developers are not fully aware of the business, this should start with the discussion of the different user groups or personas.

Then we move over to the brainstorming of stories. Presented with the objectives and the user types, everyone gets to write their own stories. A tips here is not to push the user story format. When you make it mandatory, people will debate you, but if you instead say that you want to know not only what but why and for whom and that this is an excellent form for that, you get more in a story format. Don’t be afraid to see developers and operations as users. Some stuff you need for these groups too. And writing stories with yourself as user type makes developers learn how to use the format.

 

Grouping stories

After everyone has written their stories, I usually send two or three team members to the whiteboard to group the stories. I let them decide on groups.

After that we say the stories out loud. We select the stories we need, sometimes write some more and some of the stories are discarded after we explain why this is not necessary.

 

Highest priority

I then get everyone to mark on each story if it’s mandatory or not. Everyone get’s their saying.

We then sit down and I pick up the stories which at least one person said was mandatory. I then ask the following question about each and every story:

- If we don’t do this, the project will be worthless and unsuccessful?

This will make the number of mandatory stories much much smaller. When I was more junior as a product owner/project manager I thought the mere asking if the story was mandatory was enough. But the important question is if the story makes the difference between success and failure.

If a story is still considered as mandatory we look at the objective. And I ask the question:

- So, how will this help us reach the objective(s)?

A number of stories will lose their status as mandatory right there and then.

What is the first thing to do?

The next phase is to understand what we need to know where to start. If you have multiple sub groups, you should ask each group what they want to start with. Now the team often remember The Other Stuff, as development and testing environment, setting up build scripts and all that so be prepared for some extra story writing.

When every sub group has identified what they want to start with, they must say if they are dependent on another group to start with their first task.

If the groups depend on each other, use The Theory of Constraints to specify the priority. With that I mean that you should try to optimize the usage of the bottleneck resources.

Is this it?

This is an exercise which should be done regularly. As long as you have stories, you can focus on the next most prioritized items but you will need to go through all phases many times during a long project

Using our kanban board for continuous improvement

Why do you use a kanban board? Why do you use a scrum dashboard? Really? Think about that. And then think again?

Do you track your workload? Do you calculate if you’re going to complete the sprint objectives? Do you use it to divide the work or fetch your tasks?

And why do you manage projects? Is to have something to do? To be able to track progress? Or divide work or just to feel that you’re in control of what is happening?

What ever is your reason if it’s one of the above, I state that this will not help you in the long run. Because this objectives will not improve your work.

This summer I read The Goal and learnt about The Theory Of Constraints. As always, I recommend you reading the complete book, but here is your five minute version.

All processes have constraints. You cannot remove all the constraints in the process, because if one step stops being a constraint, a new step becomes the new constraint.

A process with step 2 as the constraint

If step 2 becomes more effective, the risk is that the constraint is moved to the next step. So, you cannot just map your process, “remove the constraints” and be happy about your highly effective process. You need to work this continuously.

So, the objective is to constantly improve your process so that the effect of the current constraint is minimized and so that new constraints are identified. But how is that done.

Well, first you identify your current process. All the steps are mapped and then you see where there is some queuing going on. And here comes your Kanban board. Or your scrum board. Or what ever tool you’re using.

Here you follow the value stream of the process and by having a visual tool, you can identify your current constraint.

For example, let’s say that you’re going waterfall. What happens (probably) is that a queue forms at the testing steps. When people finally get to test stuff, a queue of bugs will start to form. And it can form quickly. The step to take then is to try to even the identifying of bugs. Hence you get continuous testing during the process. But then something else starts queuing. And you then use the board to identify that and to improve those steps.

A mistake, according to The Goal, is that we spend too much time optimizing the steps that are not a constraint. But by doing so you just add to the queue. So, if you have a problem with testing not being done, making the software coding faster is not increasing the productivity of the whole process.

I’m really excited to be working with this in TUI Nordic. We’re an organization who is working with lean values and empathic leadership, so this will fit nicely into the culture of the organization. Will it be easy? Hell, no. But a real challenge, yes.

Why don’t your estimates improve?

One question I often get is why the estimates given by developers are so bad. Why they don’t become better.

If you look at what people have estimated for the longest time, one guess is weather. I can imagine early humanoids taking a glance at the sky in the morning, estimating if this is a good day for hunting or what ever. So, our weather for casts should be great?

Well, that depends.

Having just visited Greece this summer, I became after just a couple of days an expert on weather predictions for Rhodes. It’s hot, warm and windy and when I look at the for cast for the upcoming week, I think my guess is as good as the pro’s:

But I live in Sweden and if I’m going to make an estimate of the weather for cast for the coming week, my guess is probably bad. The weather fluctuate more in our temperate climate.

 

So, when you think that your developers never “learn how to make accurate estimates”, think about the surroundings. Is the system in a temperate climate or is the weather steady as in Rhodes?

Another important lesson is that estimates are given at a specific moment. If I’m going to guess the weather in Stockholm August 13th 2010, my guess will be a pure guess, since I have no idea of the weather situation then. I can make a better guess about August 13th 2009, since that date is pretty close. So, even if you can make a prediction, this will change over time. This mean that an estimate concerning size of a task is valid just then. A month later, when the systems have changed a bit, that item can have become more or less expensive. So, don’t get upset with that developer because he gave you an estimate a year ago and he won’t hear about that today. If you want to place yourself in his position, consider the task of “getting ready in the morning”. Imagine yourself being asked that question when you are a 27-year-old without kids. Do you think that your estimate of getting ready in the morning in that situation is valid three years later when that 29-year-old has a child which goes to daycare. Just like our situation becomes more and less complicated, so becomes the situation for systems.

So, for how long is an estimate valid? Well, that is something which differs between systems and organizations. So, this you need to find out for yourself.

Why Estimate is a bad word

What is an estimate?

According to Dictionary.com the verb means:

1.
to form an approximate judgment or opinion regarding the worth, amount, size, weight, etc., of; calculate approximately: to estimate the cost of a college education.

2.
to form an opinion of; judge.

and the noun means

4.
an approximate judgment or calculation, as of the value, amount, time, size, or weight of something.

5.
a judgment or opinion, as of the qualities of a person or thing.

6.
a statement of the approximate charge for work to be done, submitted by a person or business firm ready to undertake the work.

So, why is that a bad word? Well, I don’t think it’s really a bad word, but in the case of software development, the use of the word results in some serious problems.

Case 1: A developer leaves a task unfinished, that is not according to Definition of Done. The reason is that he’s run out of time according to the estimate so he drops it or finish it with lacking quality.

Case 2: A developer starts working on “something else”. The reason is that he finished what he was supposed to in less than the estimated time and felt free to spend the rest of the time with that other stuff.

Case 3: A project manager gets upset that a project is late. The reason is that he feels that the project is late because things took longer than the estimates.

So, why is estimate a bad word? It’s because it can cause people being pushed into not completing the tasks or not doing the things that have the highest priority. It causes confusion.

And if you consider a project where Case 1 and Case 2 are common, what happens? It causes some stuff to be bug infested which probably causes later delays and you’re never able to make up the time since when the developers are faster than the estimate, instead of moving on to the next item, they fill up the time with other stuff. Observe that I don’t assume that they are surfing the web or just idling, perhaps they refactor or something else. So, it is often good stuff, but not the most important stuff. And it does not help in catching up. So, what does this lead to; Case 3. If the project delivers poor quality and unfinished work and never makes up the time, of course the project will be delayed.

So, what word is better? Planned? Don’t think so, even if Microsoft Project use that word. This word most definitely leads to all these cases. Assumption is no better. When you think about it, you just have to realize that the word will lead to misunderstandings. So, what do you do?

Well, to handle Case 1 & 2 you need leadership and here I think that Kanban is a real savior. You cannot just drop the work and you cannot use the estimate as “your time”.

But what about that project manager? When it comes to the project manager’s need for planning, it’s important for him to realize that an estimate is a guess. A good or a bad guess. And when you’re guessing, you need to know the value of the guess. I like working the PERT analysis when this is a big issue (isn’t always??). You give three estimates; an optimistic, a probably and a pessimistic. Here is an excellent presentation on PERT analysis by Ricardo Vargas.

Pert Analysis in Projects

View more documents from Ricardo Vargas.

You can also add a value of risk to the estimate. So, when you estimate something, you estimate the size and the risk. And you would be stupid if you don’t realize that if you have a big task with a high risk, you cannot take that estimate for granted.

News in Team Foundation 2010

From a project manager’s point of view

On 2009-06-25, I and a colleague listened to a seminar concerning news in Team Foundation Server (TFS) 2010. We are currently using TFS 2008 mainly for source code handling and tracking progress (using the work item tracking functionality) during projects. Here are my notes.

Fundamental changes

TFS 2010 include a new client, especially for testers, Test Essentials or Test & Lab Management. This will mean that to be able to work effectively as a test leader or tester, you don’t need a Visual Studio installation. It is today unclear how licensing will work with the new client.

The integration with Microsoft Office require Office 2007.

SQL 2008, SP1 is required.

You can run a VS 2010 client against TFS 2008 SP1 and using patches, a user can run VS 2008 against TFS 2010. This enables a step by step upgrading of the environment.

The installation of a new server is complicated and takes a lot of time. You can though make the installation first and make all configuration in a second step, This means that the person responsible for installation does not need all configuration variables to complete the installation.

The possibilities for load balancing has been increased which would enable us to runt TFS on multiple servers and also make use of several SQL Server.

Work item tracking

The most important change here is the possibility to not only link work items but actually specify how items are linked. You can for example:

• Specify a hierarchy. This would mean that we can specify which tests are included in a test plan or which tasks belong to a product backlog item.
• Predecessor/successor relationship. This would mean that we could specify that one task is dependant on the for filling of another task.
• Related items of a specific work item type. This would mean that we could specify requirements in the form of tests and we could then specify on a task Definition of Done in the form of which tests are to be passed to see the task as completed.

A smaller change is that you can group different work item types to ease the creation of reports and queries. Using our current development process, we have no need for this.

The reports are as before available in Reporting Services format but there is an increased number of Excel reports, which also use the data warehouse. This would make us less dependant of reporting services for our project management.

There is also a specific report called Agile Workbook. In this, a number of reports, focused on the product owner and scrum master roles has been gathered.

Building environment

The concept of Gated Build is introduced and means that when a developer checks in, he can make a test build before an actual checkin. This would better hinder checkins which breaks the build.

The build scripts use Workflow 4, which enable a more graphical view of builds.

TFS Admin Console

A new client, targeting the administrator wanting control of his TFS and include the functionality which an administrator needs.

Test & Lab Management

This is a Windows client which does not require Visual Studio and target the needs of the tester. Here a tester can set up test manuscripts, run tests and report bugs. What was also really interesting was that while running tests, a tester can choose to record his steps and when filing a bug, he can automatically send a film or pictures of the situation. The recording can then also be used when verifying that a bug is fixed: the macro retakes all steps to the failing step, which makes the validation faster.

What also was interesting was the possibility to set up virtual environments for different test scenarios, for example different cultural settings and configurations. Since a test is run in a specific environment, we can keep better track of the environment in which the tests are run and not run. Also, when filing bugs, a snapshot of the environment at the time of the failure is possible.

Visual Studio for Architects

The seminar did not cover functionality in Visual Studio but notable is the inclusion of modeling in UML using Visual Studio. Use cases and processes can be directly modeled in Visual studio and linked to code and work items. Also, it is possible to automatically derive a model from a current system.

Since this is stored in the source control system, the models would be source controlled, which means that you can track changes of the system and even see which checkins have changed the model.

Query handling

The visualization of a search result has been improved since you can view a tree view or a link of the items and their directly related items. You can also click and drag to move work items in the hierarchy, for example if you want to move tasks between sprints or product backlog items.

Queries can now be collected in folders and you can also make rights settings these folders to hinder users from accidently changing common queries.

Source control

You can in TFS see graphically how branching and merging has occurred and using a graphical tool merge.

Web client

The user interface in the web access has been improved and include a dashboard functionality to enable views which are specific for the different types of users.

Are you planning a project or just drawing a Gantt chart?

I guess the main reason for most project managers to use Microsoft Project is drawing the traditional Gantt chart. It’s kind of obvious, since the Gantt chart view is the default view of the program. This view is also confirmed by the default fields that are visible. A task is in Microsoft Project described by over a hundred fields but only eight of these are visible using the default settings.

If you just start up a default session of Microsoft Project and don’t change any setting, this is how you define a Task:

· Name (Text)

· Duration (Days)

· Start (Date & time, even if only the date is visible)

· Finish (Date & time, even if only the date is visible)

· Predecessors (Numbers – ID of tasks which the task directly depends on)

· Resource Names (Names of Resources)

If you open one of the templates provided by Microsoft, they all look something like this:

There are all these tasks where one leads to the other and where the assignment is already done. You’re supposed to enter the Duration (in Days).

What is important is to understand what Duration is and what it’s not. In agile methodologies such as scrum, when defining tasks during sprint, you estimate how much work a task should result in. In other words; how many man hours it is estimated that a task will result in. This attribute is in Microsoft Project referred to as Work. And that is not the same as Duration. You cannot even see Work with the default settings. Work is what you get when you add resources to a task. But why is this? I believe that it all comes back to what I assume is the basic use for Microsoft Project; drawing the Gantt chart.

The Gantt chart is made up of all these blue bars, all connected to each other and leading to the end of the project. So the assumption of the Gantt chart is that if you make a Gantt chart, you can calculate when the project should be completed. That sounds great! Just what my stakeholders want.

The individual bars in the Gantt chart have a length and a place in time. The length is the attribute Duration, and therefore it makes sense to have the attribute Duration clearly visible and editable. And to place the bar in time you can use two methods, you can either link them together or you can place them on a specific date. The linking information is saved in the field Predecessors and you can specify a date by changing the Start or Finish Columns.

The final touch to the Gantt chart is the displaying of the resources names and that is stored in the field Resource Names.

So, there you have it; the columns in the default view of Microsoft Project are the ones which you need to draw the Gantt chart.

But does this mean that you can calculate the finish date of the project based on this? Well I think that experience talks against this. Just the fact that you cannot see the assumed workload makes the planning blind. And as I’ve previously discussed; since the focus factor is 100%, no holidays are in the system and the slack is 0, we all know that this is an illusion. Looking at the Gantt chart, I see the similarity with stairways and you get the feeling that all tasks are individual steps on the stairways. You just have to walk down that and you’re done. You can just check of the steps as you fly by them. Right.

Another problem with having the Gantt chart as the objective of your planning is what you want to do with that Gantt chart. Yes, you want that planned end date but you also want to show the chart to your steering group. And then you need to print it or take a screen copy and enter it into your PowerPoint presentation. Let’s see what happens when we open one of the templates:

But hey, I can’t see all those bars, and I cannot see all those rows! But then I need to collapse the heading tasks and change the timescale:

But then I’m missing out on my nice blue bars and it looks strange. So, to keep my project nice and clean, it’s better to keep the number of tasks down. Also, linking in the Chart view is a pain if you cannot see all the tasks at the same time.

And here, we also see a conflict with agile values. In most agile methodologies, you want to keep the tasks as small as possible to enable more accurate estimates. But this clutter up the Gantt chart, making it hard to read and linking becomes complicated.

Finally, we have another problem with having the Gantt chart drawing as the objective of our planning. The product backlog does not fit into this scenario. A product backlog is a prioritized list of requirements but this does not mean that the product backlog items are interlinked. So you cannot link them in the Gantt chart. But if you don’t link them, you don’t get your Gantt chart.

Next time you start Microsoft Project, ready to create the plan for you next project, keep your objectives clear; is your goal drawing a dreamy Gantt chart or do you have higher goals?

I’ve on this blog posted a tutorial on using Microsoft Project as a planning tool. I cannot say it’s easy but neither is planning. Thinking that you’ve planned your project just because you have a Gantt chart to show your steering group is a first step towards a challenged project.

Don’t forget to harvest the passion of the developers

Most of the software developers I’ve worked with want to solve the problems of the users. Many are real professionals with the attitude of a craftsman. Many are innovative about different solutions. And most of them love to write code.

If you take a developer who wants to solve problems, is a craftsman, innovative and loves to write code you are sure to hear loads of good ideas of what he could do, if he only was given the opportunity.

Many times, his suggestions are not highest on the priority list from the business people. And then you run into the situations when his stuff is never done. Yes, I know that there are other stakeholders who’s ideas never becomes a reality too, but this guy stands there with his hands deep into the code every day, thinking about those things he could do, given that he get the opportunity.

So, you should leave some room for that in your plan. For example, if you’re using scrum or another iteration based method, let the guys pick one thing if they are successful in a sprint.

If you’re doing kanban, you can be a little bit more spontaneous. The other day, one of the developers came up with a great idea. I could see the passion in his eyes. He really wanted to do it. And I could hear that he’d given the thought a lot of thinking (this proved to be correctly later). Since we’re in a situation where the next stuff on the list cannot be completed due to lacking resources of a specific competence, I was considering what we should do next. So, why not? So, I said to him to go ahead. Given that the stuff in progress is done, this will be next.

I think we’ll get so much more code/function/quality out of this than we would have if the stuff had been done with someone who didn’t think this was his stuff, someone who wasn’t thrilled about the idea. And this joy about his work will probably continue after his work with this is done. Just because now it’s done.

But besides from sometimes prioritizing the stuff the developers have passion for, one can also help developers becoming more passionate about all the other stuff. And that is best done (I think) by including them in discussions, requirements and story writing.

Why user stories are not silly

I’m currently reading The Goal, an experience not unlike reading Godel, Escher, Bach in my youth or Sophie’s world a couple of years ago. Using the novel form to explain Business improvement (The Goal), Mathematics (GEB) or philosophy (Sophie’s world) seem like something impossible, but in these three cases the form (which, I grant, is only partly used in GEB) is truly successful. The reason is that the story format probably works well with human brains. It’s like it’s described in Made to Stick; by presenting a story, the information sticks better in our brain.

And yet, it doesn’t seem natural to even consider writing something so important in the novel form. It’s almost like if a subject is grave or important, the presentation should “fit” that. Perhaps this is also the reason for why so many question the user story format. Just the name is probably a hindrance.  Are we going to write “STORIES”. Are you going to gather all developers in a room and write stories. I guess the postits add to the kindergarten feeling most perhaps feel when presented with the user story idea in the first place. I mean, we need the developers to work (AKA, create code).

But stop and think. Like the main character in The Goal does. What’s the goal?

Well, the goal of every IT department should be the same as the rest of the company. And all companies must make money. Perhaps not today or tomorrow, but if you don’t make money, you will never survive.

OK. If the goal is to make money, what do you do next? Well, you should start moving in the direction of making that money. That does not mean that you should only focus on the things that bring in money now. That can, as you probably know, even make you lose money in the long run. Taking on customers who you can’t handle can cost you in the long run. Skipping that training for the developers can make them make simple mistakes. Etc. What is important is not taking the steps in the directions that doesn’t make you earn more money. OK, a company can of course participate in altruistic programs for help organizations, but this is just an exception. When you are at work your tasks should lead to your company making money.

But now the old lady has gone bananas. Starting with some strange books, moving over to user stories and now she’s rambling about making money. Where’s she going with all this?

If we now take that notion of making money down into the deepest corners of the developer’s department and sit down with Greg, the geekiest guy on the block. And we sit there and ask him – How will that piece of code make us make more money? What are the chances that he has no idea or worse; a false image? But why? Because some consider developers just working when they crunch code. That is what makes the company making money. If a developer is not crunching code, he’s not productive.

But what is a productive developer. Well that should be something like this:

Yes, there could also be something that could be disabled and then the two end boxes switch places, but the principle is the same. Now consider these two scenarios.

A: A user wants to do X in system Y and a change request is formed by him and the tasks are handed to a developer, who develops the functionality and delivers to the user.

B: A user wants to do X and discusses this with a developer. The developer informs the user that this functionality is already built into system Z and the user starts using that instead.

So, how was the productivity of the developer in these two scenarios?

How common do you think that this is. Or the scenarios where stuff is built more complicated than needed, or wrongly because something was misunderstood? Or the thousand other cases when the developer simply didn’t know what the user wanted and the user didn’t know his options. When presented with options (not too many but a handful) an intelligent user can often realize that he himself didn’t know what he wanted either.

So, how can we best inject the knowledge into the developer? Well, giving him that specification is a clear path to failure. And in the case of our two scenarios, the specification in itself was waste since it was never needed in the first place.

What we need are more stories. So, is it enough just to use the user story format and give the developers that bunch of story cards?

Have you seen the Dead Parrot sketch by Monty Python? When the sketch was first presented to BBC, they simply wrote down the dialog but no one could see the joke (well, perhaps you don’t like Monty and then it’s never funny) and it wasn’t until they played the stuff the greatness was spotted. And it’s the same with user stories. The actual text is just a reminder, it’s the forming of the story which brings value. Remember that the objective is making money and if we can do that without writing any code at all, we can spend that time on something else. But to enable this, we must use the competence of the developers and the business people at its maximum. And user story workshops are an excellent tool.