Archive for the ‘Chapter 5: Advices Based on Project Phase’ Category

Time Estimation

Comments Off on Time Estimation

How large portions of the work should be estimated

In software development, it is difficult to understand the complexity of a project.  It is therefore a good idea to split up the task in smaller parts where the largest part will take less than 40 hours. Large and complex chunks of work need to be split in smaller parts.  My observation in time estimation is that complex tasks seem to be 90% done and stay that way much longer than tasks that are less complex. This is the consequence of undertaking an endeavor in which you have no experience

I will present two methods that I use, both separately and together. We have used planning poker to estimate the most likely value and Lichtenberg to handle the variations.

Planning Poker

Planning poker is a consensus-based estimation technique. The method was first described by James Grenning but it gained popularity when Mike Cohn wrote the book Agile estimating and planning.

Planning Poker

When an estimation session is done, one person describes the requirements for the group. The group discusses and specifies how to fill the requirements. Each participant makes an individual estimate but does not say it.  They use playing cards with pre-set numbers. The denominators are 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100 and “Don’t know”. The values can be in either hours, days, ideal days or story points.

When everyone has played their card, the card is shown and the group discusses the estimates with those who provided estimates that were radically different from the rest.  After discussion notes are written (which might be valuable for future development) a new estimation is done. This time the estimates are more similar. If this doesn’t happen, the process is repeated. It is not necessary for the whole group to have the same number because the objective is a qualifying assessment rather than a precise time period.

Lichtenberg’s Method

Professor Steen Lichtenberg developed a mathematical method to estimate time which also provides a measure of uncertainty in addition to an assessment of the likely value. Minimum and maximum values specify the limits of uncertainty. These dimensions should be such that there is more than a 1% probability that the actual result will fall outside the min-max range. The estimates are based on certain conditions, stated or unstated, such as who should do the job. The uncertainty is processed only on those parts which are most important for the project’s total uncertainty. Because there are so many project unknowns, the min-max range will be large. The project’s end date and total cost are not stated, only a probability assessment is made.

Lichtenberg method

When doing an estimate, specific activities are discussed with a view defining what is included and how it was and will be done.  The group tries to estimate how long it will take one of the members to achieve it. This is done by the person or persons who will be doing the activity later.

When the most likely value has been agreed upon, the group estimates how long it will take to do this if everything works out great. Then the group discusses the worst case and estimates the difficulty level of the activity. When estimates of the “most likely” value, “best case” value and “worst case” value are obtained, the following formula is used to calculate the expected value.


This calculates the probability that the team will be within a 95% interval with the following formula.

So let’s look at an example.

Lictenberg Example

Understanding prioritization

Comments Off on Understanding prioritization

A project shall deliver something “a scope” on a specific time and to a predictable budget. As your project progresses, things happen differently from how you’d planned. You find that you need extra computer hardware, and some tasks have taken longer to complete than you originally predicted. To get the tasks completed on time, you consider recruiting more contractors. But, to do this, you’d have to take other costs out of the project’s budget. You think about not buying the extra computer hardware that you need, however, this would mean changing the project’s scope, so that some functionality isn’t delivered. In many projects, the budget, scope and schedule are closely linked. Changes to one of these three key constraints will most likely affect the others, or impact on the quality of the project. In order to plan and manage the project you will need to know how the customer will prioritize. They probably say they need the entire scope on time and on budget. But here is an advice to see how the customer really is going to prioritize when things will not follow the plan. When planning the project you ask your customer or product owner the following: “its two week until delivery and the two most prioritized features are not finished, what will you do?” Does he say do whatever it takes or never mind that feature or how much more time will you need. Or he might say takes as many shortcuts as you can. This gives you an idea of how privatization will be in when things starts gets pressured.


Different prioritization themes

It’s rare that we have the time to everything we need to do, so we need to prioritize. The agile methodology is preaching that you shall prioritize to maximize the business value, but often business value is something vague. And at the same time you should prioritize knowledge acquisition and risk minimizing. I will introduce you to four different prioritization themes and show how you can use them and combine them in order to know in which order you shall implement your project.


  1. The financial value of having a feature.
  2. The cost of developing (and supporting) the new feature.
  3. The amount and significance of learning a new knowledge created by developing the feature.
  4. The amount of risk removed by developing the feature.


Because most project are undertaken either to save money or to get new opportunities for making more money, these first to factors often dominate prioritization discussions. However, proper consideration of the influence of learning and risk on a project is critical if we are to prioritize optimally.



How much money will the organization make or save by having this new feature. This is often what is meant when products owners are given the advice to “prioritize on business value”. The ideal way to determine the value of a feature is to look in its financial impact over time – usually the next few month or possible years.



In order to judge if something is worth doing you must weigh value against cost. Many features seem wonderful until we learn their cost. When considering cost is important to evaluate the cost over time, some features cost more to maintain than to build. Adding language support might be cheap but slow us down and cost a lot to maintain. It might be better to wait with that a couple of month.


New Knowledge

In complex projects much of the overall effort is spent on perusing new knowledge. The knowledge can be either what shall be done or how it shall be done. If the team has no prior experience of something, start as early as possible with that task. You can do a proof of concept and it will help you to uncover the borders of the technology you using. It could also help you to agree upon requirements, because when people see how the programmer interpreted the requirement you’ll be able to see if it is what the customer expected. If the customer or the stakeholders don’t react, that is also good news – that mans they thing you interpreted their view.

By prioritizing features that have a big impact on the system and develop them iterative and deliver the system to users frequently helps you to learn new knowledge. Complex products biggest risk is probably the risk of building the wrong product.  This risk can be dramatically reduced by developing early those features that will best allow us to get working software in the hands of actual users.


Risk is all about the knowledge you don’t have. A complex project becomes complex because we don’t know “what we going to do” and “how we are going to do it” and at the same time have a lot of expectations on what the project shall accomplish. Risk is anything that has not yet happens but might and that would jeopardize or limit the success of the project.  There is many kinds of risks they can be outside the project “What happen with the system if the company is split?” it can be a schedule risk “If this doesn’t work we will not be done by April” or a functional risk “We might not be able to get that to work”.


There is a classic struggle between high-risk and the high-value features of a project. Should the team start on high-risk features that have a big impact on the system, the things that if they go wrong have many dependencies to all part of the systems and just must work. Or should the team focus on the low hanging fruits, which will deliver most bangs for the buck?


Conclusion of prioritization

There is no ultimate way to prioritize! But it might be good not to just look on one parameter like value or value/cost. And the preferred method should probably link to the project main enabler, saving money or getting new opportunities. You can also combine different aspects like risk and value.

Everyone wants Change, but nobody likes to be Changed.

Comments Off on Everyone wants Change, but nobody likes to be Changed.

I often get the question how do I convince my manager, customer or team to change? And the answer is you don’t! How do you like being “convinced” by a salesperson?


The only person you can control is you, if you can’t change yourself, how can you expect to change anyone else? If you can’t make yourself or other motivated of change nothing will happen. People need to feel that they know that the “journey” is worth doing in order to reach a goal. And people only feel that they really know if they have personal experience from something. So how do you solve this moment 22, which you don’t feel that you know until you do it, and therefore don’t know that the journey is worth undertaking?

Causes of resistance

There are many causes why someone might not be motivated to change.  Here are some causes of why people might not want to change;

  • Don’t see any problems with the current situation. Why change if things work!
  • Doesn’t see any path to the goal. Don’t see a natural next step.
  • Don’t see that we are making progress. Why change if nothing ever gets better?
  • Doesn’t understand the destination or agree the value of reaching it

Trying new ways of working

The easiest way to solve this is to try in a small scale, so that you get some personal experience.  Don’t do big bang changes but try different things and evaluate if it works for you, do it both incremental and iterative. See if you can measure the change, do you become more productive and do people like it. There are no ultimate solutions; there are no “silver bullets”! There is only hard work, and continues improvement. And in order to improve you will need be prestigeless and realize that past ways of work haven’t been optimal.


Planning is Guessing

Comments Off on Planning is Guessing

Looing in the starsIf you’re not a future teller planning is guessing. Strategy is about continuously choosing what to lay your effort on. A soccer game is 90 minutes long and if you run on every ball you will get lactic after 4 minutes.  So strategy is about letting you team know what to put their effort on, which situations that helps us with our long term goals, so the team members recognize situations where it’s worth the effort. They know when everyone else in the team will join in and help you and at the same time know there role in the game. Some are middle field players the help get the ball up and are pushing things up the forwards. It’s the same in projects not everyone talks everything from idea through development and deployment. If you don’t got a strategy people will not be able to recognize situations where the whole team will come together with the whole team effort. People will run be able to judge the value of a situation. Better planning, as Mary Poppendieck (author of “Lean Software Development”) points out, results in a higher standard of living for the individual, for the team, and for the organization.

The Plan is Worthless, Planning is Everything

Comments Off on The Plan is Worthless, Planning is Everything

Creating a Project Plan

For all stakeholders and team members to create a mutual understanding of the project’s direction and goals, it’s a good idea to document expectations and the means for meeting those expectations. This is called the project plan.

Making a plan

Depending on the type of project,  the purpose of the project plan will differ. If it is a very formal project, it is primarily written for the project client or product owner. The degree of detail contained in the project plan will depend on how formal and plan-driven the customer is and to what extent he wants these details laid out.

The Plan is Worthless, Planning is Everything

Plans are great for complex projects because they set the direction and the alignment of goals. However, the value of the plan decreases over time.  Is it realistic to plan all activities upfront? Projects live in a world of constant change and new insights are gained so planning on a detailed level for a six-month timeframe isn’t practical for software projects.

This is one of the foundations of agile methodologies. For the short term, when an overview is created, detailed planning is helpful. But for the long term, a plan is simply to set direction. Discoveries about the project will be made, you become wiser from gaining all that additional knowledge and you change priorities.

The parallel to sailing

SailingI’m a passionate sailor. I have spent my vacations sailing since I was a child. Each morning we plan where to go and what to do. We use charts to see what to expect during the day and which milestones we can establish to make sure we’re on the right track (milestones).  When we start sailing we don’t see our goal (destination) so we rely on our milestones and compass.  On windy days the waves splash against our boat and the sea looks dramatic.  Looking beyond the horizon, the water appears calm. Reaching our final destination is as dramatic as the enormous waves we encounter.

It’s the same with project plans. From a short-term perspective, you get an overview of the drama, but from a long-term perspective, you can only rely on your compass and milestones.

A common timeframe for detailed plans is 3 to 4 weeks. In Scrum, a common iteration is about 3 weeks’ worth of work. In the beginning of these three weeks, the sprint is planned in detail.

Projects are like sailing trips: changes occur often because of the need to adapt to changes in the temperature and oceanic conditions.

Activity Planning

There are different ways to start planning the trip from A->B. It can be hard to cope with dependencies and the order in which things are done. A good step is to identify the whole work package in the beginning and then break it down one at a time. Brainstorming will facilitate project delivery.  Another way is to start with the goal and go backwards. To deliver we need to submit our application to the AppStore at least 3 weeks before the “release date.” Another 2 weeks is required for testing and other related tasks.

Activity planning


Large and complex projects can be divided into smaller parts and be planned as single units. Milestones serve to monitor progress and allocate resources. A milestone should have a clear goal that is related to the project’s outcome. Milestones are essential in controlling projects. When combining activities with milestones you can make a critical path method, helping you to identify risks of schedule slip-ups if a milestone is missed.

Critical Path Method

Many projects fail to meet scheduled expectations because there is a timetable slip-up in an activity. The Critical Path Method is a technique that is used to predict total project duration and helps control project overruns. The method takes the different activities and relates them. The critical path can be identified, as well as identify the longest path where there are dependencies in relation to other activities (marked red in the diagram underneath). For effective control of activities, these are the ones to watch and monitor.

Critical Path Method

Creating a Group and then a Team

1 Comment »

The point of working together is because the sum of everyone’s work is superior than each individual work. More gets done in a shorter time. The point of working together is to bring together the different skills required for a complex project.

This blog post I will discusses group psychology, which is a field of study that can be valuable to leaders and managers. Software development is about cooperation between humans so this will be an an indispensable section of this book.

No group ever becomes a team until it holds itself accountable as a team.

“The wisdom of teams” by Jon R. Katzenbach

What is a Group?

A group is more than a bunch of people; they have common interests. A group consists of two or more people who are socially related. The more interaction there is within a group, the more influence members have on others, potentially leading to changes in their attitudes and behaviors.  After working together, norms and values are developed within the group. There is something that distinguishes the group from others. Some call it team spirit, a group members could describe it like this group have specific norms and values. Let’s visualize two people (A and B) who have some kind of relation (C).

What is a group?

The more (A) and (B) add to the relation (C) the greater and more important the relationship (C) becomes. If both (A) and (B) think they deserve to get more from (C) than what they each contribute to it, the lesser the relationship (C) becomes.

A friend told me why he broke up with his girlfriend: “I didn’t get enough from the relationship, there was nothing left between us anymore so we had to break up!”. It’s when 1 + 1 equals more than 2 a

than required, the group feels a stronger bond and shares a common vision.
Read the rest of this entry »

The Knowledge Cake

Comments Off on The Knowledge Cake

A project is a temporary organization created to help the line organization. This means that the knowledge for a specific project comes from the line organization. When a project starts, the knowledge of what will be accomplished often looks like this. If you doesn’t have access to a line organization that have any previous knowledge about the domain it’s becomes much harder. Then interviewing future end users becomes the only way to secure that you are on the right way.

The Knowledge Cake

When the project ends, we have identified many of the things we didn’t know before the start of the project. At the end of a project, it is important to transfer the acquired knowledge back to the line organization or the one that will work with the system. The big challenge is spread the knowledge about why things become in a specific way, often a lot of considerable has been taken into different solutions and when a specific solution is chosen the team often know why it couldn’t be done in 9 out of 10 other probable solutions. Often only How and What are documented and why is forgotten and never documented, and it’s often the question of “why” you comes back for when rebuilding part of the system in future development. The question of how and what are quite easily documented in software development. You can look on the database or the source code. It is therefore a great idea to sum up how you got to the specific solutions after design workshop so the question of why also can be traceable.