What to consider when growing a software team

A few weeks ago, we had the chance to do Myers-brigs at our office. As it turns out I am an INTJ. You can find your own type on this site human-metrics.

As a base rule, mixing individuals from different personality types leads to better creativity albeit at the expense of efficiency.

Developers, in particular, have an even more nuanced environment. Fred Brooks famously said:

The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures....

This means as you grow your team, there are certain things to look out for. In this entry, we will be exploring the factors I think are the most important.

Does the team structure compliment individual’s strengths?

We perform best from a position of strength, yet somehow team leaders assign individuals to tasks optimised for the organisation rather than for the individual’s strength.

A simple test such as the MBTI can help you easily see who would work best with who.

As Wegner proposed in 1985 the greater intelligence born of the group mind which comes about from great collaboration is guaranteed to benefit your organisation.

Is anyone multitasking?

Human’s can not multitask. The illusion feels so powerful that the team leads don’t even need to push this agenda, the developers will take it upon themselves to do it!

Despite numerous studies, including this one Who Multi-Tasks and Why? Multi-Tasking Ability, Perceived Multi-Tasking Ability, Impulsivity, and Sensation Seeking we still assign developers to multiple projects.

Two projects are optimal for an individual developer, in this way, they can switch to a different task to give their mind a break and some room to chew on the project. Anything more is likely to lead to reduced productivity as the mind becomes too clouded.

Have you limited the team size?

We have limited cognitive ability in terms of the number of individuals we can maintain in our circle. Known as Dunbar’s number, it is shown we can actively keep at most 150 active social contacts.

I believe working groups are even smaller. Once the team size gets to more than 5, communication issues start sipping in. It becomes that much harder for the team to build and maintain a shared mental model.

Mike Cohn has an even simpler rule, no team should be so big it can’t be adequately fed by two pizzas!

What is the team’s purpose?

Shortly after joining Moringa, I was having problems getting the team to work together let alone towards any goal. I explained my dilemma to the CEO. She asked me, “Have you carried out a values exercise?”.

This question changed how I think about teams, yes we can impose what we want to the team, but the team just like any other complex system will work towards its own goals.

The only way to get your team to succeed is to imbue them with a sense of purpose which aligns with the organisation.

Can the team deliver the product from end to end?

A basic tenet of the scrum and agile methodologies, in general, is the concept of the cross functional team. The simplest definition I could find of such a team was:

A cross-functional team is a group of people with different functional expertise working toward a common goal.

Cross functional teams are the killer feature of agile. They bring about diverse views to the teams enabling good ideas to be quickly tested, built and shipped.

How long do the teams stay together?

In a previous entry, Stop killing your teams now! we discussed the tragic fate of most teams.

I believe now as I believe then, teams should be built for the long term. Like the tired cliche of the good wine, good teams get better as they mature.

How do you grow teams in your own organisation?


Core technical practises for your scrum team


Scrum is a fast moving development style. There is obviously a lot of advantage to this, but just like a sports car needs a better technical design to function at top notch, so does your code.

In this entry, we will be looking at the top three technical practices that you must adopt to ensure you are moving as fast as you could be.

Test driven development

A few days ago, our team was faced with the challenge of stress testing one of our applications. One particular use case proved particularly hard to do, the only way to run it was to literally have an actual human run through the steps!

This might be fair if we were doing UX testing, but in this case, it proved to be a big red warning sign on our architecture.

We have since worked to correct our process, but the point here is TDD helps you unravel problems before they become Problems.

By writing the test first then the code, you are forced to think through what it is you actually want to do. This makes your code clearer as well.

Not to mention, by having a “second opinion” on the validity of your code, you can deploy far faster knowing another system is checking the integrity of the entire product.

Continuous improvement

If you have ever struggled with your weight, I am certain this thought has ever come up in your mind at one point or another

Let me just eat this burger, I will work it all out later in the gym

A fantastically bad idea! Not because you will procrastinate later and not visit the gym, thou this is likely, but because you essentially threw a good chance of working towards your goal and worse compromised your future self.

In the same way, almost every day you jump into your code, you will come across an opportunity for improvement perhaps a better design pattern to adopt or even just to maximise on an opportunity to reuse code. Here you have the choice of either saying you will just do a patch now and fix it in the future or just fixing it now.

The formal term for it is refactoring and there is a wealth of knowledge out there on how to do it.

By continuously improving your code, not only will your code not rot but you will have code that gets better with age.

Collective ownership

Open source software tends to be of a much higher quality than propriety code.

We all care more about what we know someone else will look at than what we are sure only our eyes will see.

The long and short of it is you want as many eyeballs on your code as possible. Obviously open sourcing your code may not be the ideal solution, but what about having your team members work on the code together?

There shouldn’t be a part fully designated to only one developer, this gives you two key advantages:

  1. Not everything goes to hell if the developer goes on holiday
  2. Everyone cleans up their code just a bit better

Continuous delivery

In 2001, Paul Graham wrote one of the most prescient essays I have ever come across, it is titled The Other Road Ahead.

One of his key arguments revolves around the fact that faster code-test-deploy cycles lead to higher quality code.

I fully agree with this argument. Continuous delivery is guaranteed to significantly reduce if not eliminate the stress which comes naturally with software development.

No longer will demo day be a day of panic. For all intents and purposes, it will just be another day in the life of the boss developer.

I hope these pointers will help you towards a better scrum experience.

Which practices here do you use in your own practice?


What are the different types of requirements and why does it matter?


A software product is usually built with a purpose in mind. There is a reason a good number of web application domains end with “.io “. It literally means Input Output.

Your product takes in some raw information and returns more valuable processed information.

As usual, the devil is the details. What does raw information mean? What does output mean?

Scrum typically adopts user stories as its template for expressing its requirements.

This simple structure of:

    As a __
    I want to___
    So that __

Elegantly captures what the software should do and why.

Still, as the product gets bigger and the requirements pile on, I find it useful to impose some categories on the backlog.

In this entry, we will be looking at some categories which I have found to be useful.

User requirements

At iHub, we pride ourselves in our Human Centered Approach. The simple reason is it works.

The software serves people. At the end of the databases, activity streams, object storage etc is a person trying to get something done. Your success is measured by how successful this person is.

It then helps to acknowledge user requirements as a category on its own.

A typical requirement would be

    As a *researcher* I want to *have my results sorted by relevance* so that *I can get my work done faster*

Business requirements

We talk about the wonders of technology, from the aeroplane to the mini computer in our pockets. Yet, I would argue the biggest invention by humans was the enterprise.

Businesses, are the engines of our society, working behind the scenes, they provide us with all our material needs.

No matter how good, the software or how well it serves the users, if the business does not provide value to its owner then it’s as good as dead.

With this in mind, you must seek to also clarify why it is the client wants the software product built in the first place.

This is usually captured in the client’s vision statement. Of this, the software serves only a part of it.

An example of vision statement from Amnesty International

A world in which every person enjoys all of the human rights enshrined in the Universal Declaration of Human Rights and other international human rights instruments. 

If you happen to be contracted by Amnesty International, you need to remember to imbue this inspiring vision in every line of code you ship.

Non-functional requirements

Robert Gardy in his 1992 book Practical Software Metrics for Project Management and Process Improvement

Came up with the acronym FURPS+

This represents:

  • Functionality
  • Usability
  • Reliability
  • Performance
  • Supportability

The “+” in FURPS+ also helps us to remember concerns such as:

  • Design requirements
  • Implementation requirements
  • Interface requirements
  • Physical requirements

The idea is in addition to doing what it does, software is also required to do it well.

How effective do you think Google would be if it took 5 minutes to give you a response to your query?

I believe by categorising your backlogs in this way, you will able to get more ideas on what is to be included in the final product as well as appropriately prioritise the various backlogs resulting from it.

How do you categorise backlogs in your own organisation? How did you handle it? Talk to me in the comment section below or on my twitter @jchex


Where do unrealistic schedules come from?


This situation is so common, it is by now something of an industry standard. There is almost no project that I have stepped into that had an appropriate amount of time scheduled for it.

You have to wonder why after all these years we still suck at allocating enough resources to get the project done in time.

In this entry, we will be looking at some of the common factors that lead to unrealistic schedules.

External deadlines

Development happens in a context. Unless it is a hobby project, you can be sure that whatever you are working on, someone else is depending on your work output for them to do their job.

A special case would be where the bid specifies the timeline in which the product must be built. In this case, submitting a longer timeline, even if justifiable may mean losing the project.

Since the project is still of interest to the team, the team takes it on knowing full well how tight the deadline is in the process displaying a mix of childish optimism and wishful thinking.

Best case estimates

Murphy warned us:

    Whatever can go wrong, will go wrong

Scrum and other agile techniques give us robust estimation tools. But even with those, we more often than not end up with a range, say 3 – 5 months.

Unless you don’t like promotions, who wants to go to the boss with the higher estimate?

Of course, the problem with the lower estimate is that it holds the implicit assumption that everything will go right.

This is a dangerous assumption, you take it for granted that you have the best tools, language, physical environment, skills etc. When something does eventually go wrong, you find yourself with an unrealistic schedule.

Feeling up to a challenge

For reasons that are beyond me. Some developers prefer working under insane conditions. Something about an all-nighter makes them feel like heroes.

Whether inspired by cut throat work environment or personal bias, teams in these kinds of environments will consistently underestimate how long the project will take.

Even if the pressure is acceptable in the short run, the effect on the team morale and product quality are bound to suffer. Better to have a reasonable schedule and spend any extra time beefing up the quality.

Belief that developers work better under pressure

Authors of the Design Sprint state:

    Times of need can be artificially manufactured by creating deadlines. Our brain doesn’t know the difference. When you create deadlines, your brain stops procrastinating and gives you what you need.

It is easy to extrapolate this kind of thinking to the entire project.

While you do need to pace yourself, you need to be very careful of the kinds of commitments that you make. In a previous entry Estimates, Targets and Commitments. We looked at the dangers of confusing the terms.

You don’t want to make a commitment to your client based on the belief that somehow the deadline will boost productivity if you must make such a commitment, let it be internal.

Scope creep

Inevitably, new ideas will come in. Change is a core part of the software development process.

The problem arises when new changes are introduced to the project but nothing is removed from the backlog. As new features are added, eventually the entirety of the work pushed the project to an unrealistic one.

We have looked at this problem in greater detail here Managing scope creep. The TL;DR is any new change is also a chance to renegotiate commitments.

Have you faced unrealistic schedules in your own practice? How did you handle it? Talk to me in the comment section below or on my twitter @jchex


Sprint is over, now what?

You have just completed your development sprint, done the demo and the review, what next?

The easy answer is jumping into the next sprint. That is of course until the end of the year when reviews are up and you are asked to specify what you have been doing the whole year.

Showing working products is great, in fact, the agile manifesto clearly states:

Working software over comprehensive documentation

Note that they didn’t say No documentation!.

Even if they did, what seems very clear in your mind right now about how the days were used may not be so clear months from now.

Thus my recommendation is that you write a brief report for yourself. It does not need to be official. You can even just call it skipper’s log.

Below are some suggestions on what to include in the report.

Notable events

Not everything that happens in a sprint will be seen in a demo. Perhaps Rico, your new developer, mastered SQL or your team was acknowledged during all hands and other search achievements.

If you do this consistently enough, you will have your team’s story, one that perhaps you can celebrate at your end of the year party, use to review salaries or make decisions on how and what to invest in the team.

Sprint dates

Of course, the start and end dates of the sprint are obvious, how could they not be? Still, the past has a way of blending into what seems like one long day. In this cases, it helps to know that the Sprint commenced on 5th June and ended 15th June and that within this period there happened to be one public holiday or a team mate’s birthday.

This information may give you insights in future planning sessions, specifically how blocked of days for development play out in practice.

Team velocity

Thankfully, most project management tools aimed at software teams will automatically compute this for you. If yours doesn’t. It may be worth it to do the computation yourself.

Velocity = Total story points done in this sprint
Average Velocity = Total story points complete/Total sprints done

You can then chose to plot this information in a burndown chart.

You may want to consider printing out the burndown chart and hanging it on your team wall if you have one.

Retrospective actionable

Your retrospective will likely come up with good practices for the team to implement in the future. While this information is already captured in the retrospective document, I consider this information so important that a little bit of redundancy is allowed. In short, have it in your skipper’s log as well.

This will allow you to quickly reflect on what you thought at the time was important to improve on and thus see how things have evolved since then.

Sprint summary

This would be a subjective account of how the sprint was. With all the talk about objectivity in our industry, telling you to record your subjective experience sounds rather counter productive.

Still, I have found that AHA moments can come from reflecting on your state of mind in action.

What do you, as an individual do at the end of the sprint? Talk to me in the comment section below or on my twitter @jchex


How effective is your application?

One of my colleagues at iHub has an interesting work philosophy. He usually says:

    I will not work on any project that is obviously a waste of time no matter how much I am paid.

This obviously reflects a great craftsmanship ethic. Such a philosophy does remain useful throughout the entire organisation. No one wants to waste resources on projects that are not going to bear any fruit.

In this entry, we will be looking at how you can test if your application is fit for its purpose.

That is, does your application generate value for your users?

Are your users able to achieve the stated goals?

User stories are a potent way of expressing requirements. I have previously talked about them in more details here Invest in user stories.

They specify what a user is trying to achieve and why.

As you are developing your application, you need to continuously reflect on your user stories and the emerging application asking yourself the following questions:

  1. Can the user meet their goals?
  2. Are there any barriers?.

An example of an issue that may be noted is particularly slow load times. If a user has to wait more than a few seconds to say input a new item on their shopping list, they may quit the application having not met their goal.

How are users using the application?

A software application is a type of system and thus displays systems behaviour. In particular, no matter the goals of the designer, once the system is live it starts manifesting its own goals.

This will be evidenced as users using the application in ways that were not envisioned by the designers.

For you, this is a great learning opportunity. The new uses can be detrimental to your own interests or they can be beneficial and thus help shape the product roadmap. Either way, you gain value from observing how people use the application in the wild.

How are the users already solving the problem?

Evolutionary biologists have a saying:

    Evolution is cleverer than you are.

Humans are incredibly creative. Your target user has probably found a way of solving their problems in some other way. It may not be as effective or efficient as yours but be assured that it is there.

Before word processors, there were text editors and before that there were notepads. More generally, ideas are conventional, they have a history that you can track to gain the deeper understanding of the problem and how the solutions have evolved over time.

By looking at how users are currently solving the problem, you can minimise the learning gap and have your users being productive in your application ASAP.

Can you test competing ideas?

In the course of development, you are likely to come across two or more viable ways of solving the problem. If they both seem to have equal weights, why not let the users decide?

For web applications, this is particularly simple, you can use A/B testing.

In this method, you go through the following steps:

  1. Define what you are trying to test eg Home page with carousel of your products or one with your latest offers
  2. Define what metrics matter to you eg click through rates
  3. Develop the MVP for both pages
  4. Roll it out randomly assigning incoming users to the pages
  5. Monitor your metrics on both pages
  6. Make a judgement call based on the data

This simple method gives you unambiguous feedback on how to proceed with development.

How do you gauge the effectiveness of the applications that you build? Talk to me in the comment section below or on my twitter @jchex


Factors in selecting iteration length


Development in Scrum happens with iterations or sprints. An iteration is a time-boxed period within which development is done. During an iteration, the team transforms one or more imprecise requirements statements into coded, tested, and potentially shippable software

Iterations are a core part of Scrum. They allow for the development team to quickly converge towards building what is of most value to the customers.

The iteration length is typically 2 – 4 weeks. This is not a hard figure. Some teams have iterations that are as short as 1 week and others have 8 weeks sprints!

In this entry, we will be discussing some of the factors that lead to variability in iteration length and what you should be considering as you are deciding on your own iteration length.

Length of the project

Projects tend to vary in length. I have worked on projects that lasted only a month and some multi-year.

Longer projects offer the luxury of a window of correction. That is if after the end of an iteration the client discovers what was built is not what they expected, there are a number of other sprints that are available to the team to correct the issue. Shorter term projects lack this kind of luxury.

Thus the length of a project acts as an important factor in choosing sprint duration. The longer the project length, the longer the sprint length you can afford have. In fact, if you already know how many reviews you want to have, you can derive the length as follows:

    Duration of sprint in weeks = Total project length in weeks / number of reviews

For example, if the project is 2 months and you want at least 4 reviews then the duration of the sprint will be

    Duration of sprint in weeks = 8 weeks / 4 = 2 weeks

In addition to allowing for more review periods, longer projects can also more easily afford the “costs of iteration”. The costs of iteration refer to the extra time used to facilitate iterative development. This would include such things as:

  • Iteration planning
  • Retrospectives
  • QA
  • Convergence

This means that for longer term projects, you can afford longer iterations and associated time costs. For very short projects, the costs can also influence the length since you don’t want to spend all your precious development time on this supporting activities.

Clarity on product and team

Some projects are simple even if they are not easy. This means that it is easy to communicate what is required and changes are not likely to come during the development phase. These kinds of projects are very rare to come across, most projects are messy especially at the beginning.

Thankfully Scrum thrives in the kind of complex projects that exist in the real world. It does this by ruthless application of Palchinsky principles.

    First, seek out new ideas and try new things; second, when trying something new, do it on a scale where failure is survivable; third, seek out feedback and learn from your mistakes as you go along.

You see, iterative and incremental development is about generating feedback, learning from it, and then adapting what we are building and how we are building it. Sprints provide teams with the mechanisms for doing this.

Thus the more uncertainty you have in your project, the shorter the sprint should be.

Uncertainty tends to come in two distinct flavours. First one is, what are we building?. This is the product question and relates to meeting the client’s conditions of satisfaction. The second one is, how are we going to build it?. This relates to the team’s development practises. You may, for example, want to run short sprints at first both to quickly show the client what the product will look like and establish the team velocity.

Since for highly uncertain projects the priorities change quickly, shorter iterations ensure that what you are currently working on is what is most important.

Stakeholder availability

At the end of the sprint, the development team needs to do a demo to the stakeholders. Your stakeholders maybe extremely busy or important individuals whose time is hard to secure. In this cases, it may be wise to plan your sprints according to their schedule.

For example, if the executive team meets once every month, it may make sense to schedule your sprints so that a demo day falls on that day. This way the hard work of convening all of them is already done for you.

You, of course, don’t want to vary sprint length from sprint to sprint. Thus you don’t want to unduly sacrifice your process in service of the demo day unless a good synchronisation opportunity exists.

Stress levels

What iteration do you think induces more stress, 2-week or 4-week iteration?

I have asked this question to a good number of my friends, the answer is almost always 2 weeks. They are wrong.

It may not seem like it, but longer iterations tend to induce more stress than shorter ones. This is because longer iterations have well defined, beginning, middle and ending points. Naturally, the team is a bit more laid-back at the beginning and gets more stressed as the deadline approaches.

Shorter iterations smooth out this effect, the team can then settle into a manageable tempo.

See this masterful piece by Tim Urban

How do you select iteration length in your own organisation? Talk to me in the comment section below or on my twitter @ jchex


Sources of change in a software project


Change is an integral part of the software development process. It’s what makes software soft. In fact, change is so important in software that it get’s it’s very own line in the agile manifesto

    Responding to change over following a plan

It’s been a long time since software teams believed in the unchanging quality of requirements documents, but we are yet to fully understand where change comes from and how it affects us.

It costs far much more to make core changes during development than it does at requirements. Boehm and Papaccio estimate it at 50 – 100 times more. Even with the advent of agile techniques, it is still worth it to control change as much as possible.

In this entry we shall be exploring the various sources of changes, this should hopefully help you anticipate and identify impending changes as soon as possible.

Change from the customers

Of all the sources of change, this is the one worth most consideration. The reason is that as a consultancy or even engineering department, you want to harness change as a competitive tool for your client.

No matter how well you run your requirements gathering sessions, there are requirements you are bound to miss. This is because knowledge builds on knowledge ideas on ideas.

To illustrate this point, think of a car. The first car was a very basic box with wheels that happened to move. But from this idea, people began asking questions such as:

  • Why can’t the seats be more comfortable?
  • Why do I have to be hot in the car?
  • Why do I have to manually change gears?

Today, these previously extraneous features are deal breakers.

In the same way, once development has started, your customers are guaranteed to have new ideas as they see your progress.

In this kind of situation, you want to carefully weigh your options. You don’t want to do exactly what the customer wants you may end up always chasing after the new shiny thing. You also don’t want to completely ignore their wishes under the guise that you know best.

Change from sales and marketing

This part particularly affects product companies.

The product owner declares this Big Hairy Audacious Goal

    We will build a one stop best in class application within the next 6 months

This is a great goal and everyone is excited about it. The engineers get to work “banging” it out. Somewhere within the development window, the competitor does a release that you had not even thought about. The sales team also wants to be able to sell the new feature so they insist that is also put in the product after all our product is best in class right?

It is tempting to think of your application as a big checklist of features, this is dangerous because then you will be locked in competition with other firms to produce more and more.

Kelly Walters makes a compelling argument in Agile Principle 8: Enough Is Enough! that you likely don’t need to develop 80% of the features.

Perhaps then the product owner should have come up with a better goal say

    We will build a product in the next 6 months that will improve our customers margins by atleast 10%

Change from developers

Developers, my favourite group!

More than any other stakeholder, developers have the highest intellectual and emotional investment in the project. They are the ones who had to deal with the design flaws, unexplainable bugs and late night coding.

Yet to them, requirements are usually provided as a checklist. In this case am also looking at a list of user stories as a checklist. Without an organising theme, developers will do what they do best, write the best-designed code that they can conceive off.

The problem here is that the devil is in the details. Your DBA may end up writing code that shortens query time from 10ms to 1ms. This is great, except for the fact that no one really specified that they have that requirement. Another example would be where your front end engineer goes out of their way to guarantee that the settings page will work for all screen sizes.

I believe by actively watching out for this sources of change, you will be in a better position to manage them when the changes do come.

What are the sources of change in your own projects? Talk to me in the comment section below or on my twitter @ jchex


What is in an estimate?


It is easy to think of an estimate as one figure. Intuitively, it would seem that a feature such as a user management dashboard should take 5 days to build.

When we ask for an estimate from a developer, then what we expect is this single number.

Yet this single number can be quite misleading as we talked about in Why you should never give off the cuff estimates

You see the number of days it will take to complete any feature is not some kind of physical truth, rather it’s a derived quantity.

In this entry, we shall be looking at how the variables that determine the final delivery date interact with each other.

A trip home

I live and work in Nairobi, once every while, I travel to my hometown in Kisii county. Suppose I called home and told them am coming, the very first question they would ask would be

    What time do you expect to arrive?

This question is a simplified version of a client asking a developer, When can I expect feature X?.

Based on my experience travelling home, I probably would be able to give my family a solid estimate fairly quickly. But let’s suppose I did not know much about the trip, then how would I go about coming with an estimate?

How many Kilometres are there between Nairobi and Kisii? (Size)

This is the most important variable and the only one that exists independent of my activities. The distance between Nairobi where I am and Kisii where I want to be is representative of the work that needs to be done.

It is highly likely I would be able to agree with other people on the distance if nothing else.

If our estimate of the distance was to vary, then we probably don’t have a shared understanding of where we are trying to go. Eg if I estimated the distance to be 500km and my brother estimated it at 800km we are probably talking about different destinations or thinking of different roads.

In software, story points are used to indicate the size of the feature. Estimates of story points from different team members tend to cluster around the same value. In case there is a lot of variation, a discussion should ensue. It is probable that there is some misalignment in what the feature is about.

What are my means of transport? (Velocity)

When it comes to speed, means of transport is the most important factor. Will I, for example, be walking, driving or taking a flight. The different means have speeds that once more cluster. For example, walking can be done at 5km/hr driving at 100km/hr and a flight at 800km/hr.

Velocity is likely to vary even for the same classes of transport.

In software teams, velocity is measured via either story points/sprint or features/week. I personally prefer the first measure. While you can estimate this value, the most accurate values would come from looking at how you have performed historically. That is, what is the average velocity you have experienced over the last say three sprints.

The velocity is determined primarily by the skill level of the team followed by the morale and number of team members. In engineering folklore, it is said that the best engineers are 10X as productive as average engineers. Whether this is literally true or not, from experience, I know that progress is much faster with a senior team.

In an ideal situation, how many hours will it take me? (Duration)

The road to Kisii is full of perils. From a couple of black spots, flash flood areas, escarpments and corrupt public officials, there is a lot that can delay your trip. Even with none of this dangers, something as simple as having lunch is likely to increase the time it takes to get home.

So when we think about the ideal situation, we must think of the sunniest day where everything is clear and you maintain a constant speed from Nairobi to Kisii.

To derive duration we can, therefore, employ some basic math:

    duration = distance/speed

By using this computation, we can then arrive at the ideal time it will take to arrive.

Similarly, in software, we can calculate the number of story points or features we will deliver in that time period.

    time to delivery  = story points to deliver / velocity
    weeks to deliver features = no of features / features  per week

In practice how long will it take me? (Calendar time)

In real life, you have to eat lunch. Our task at this time is to determine how much time we will take considering the vagaries of life.

Suppose from previous trips, I know that I usually face some delays such as:

  • Jam at the escarpment (1h)
  • Slow traffic at flood plains (0.5h)
  • Lunch (0.5h)

Once I have arrived at my ideal duration, I would then need to add these hours to it to arrive at the calendar time.

    estimated calendar time = ideal time + expected delays

Similarly, in software, there are a lot of factors that affect feature development that is not part of development. In the entry When to ignore historical velocity we talk a bit about such factors.

So then for the software team, once you have arrived at your ideal duration, you can now add in external factors to the estimate to come up with the calendar time. This value is what the client and other stakeholders will likely be interested in. To ensure the estimates are dependable, consider some of this tips

Do you decompose your estimates and in what way? Talk to me in the comment section below or on my twitter @ jchex


Why you should never give off the cuff estimates


This had been one of my longest meetings thus far. You see the team I was in, I was the only developer. The rest of the team was made up of different professionals including designer, UX specialists and animation engineer. Each of us was giving an update on what we were working on. From the buzz of the meeting I heard my name mentioned and the boss asked me “So Chencha how long will it take to enable applicants to use their existing profiles in their applications?”. Without much thought I immediately replied “five days”. The boss typed my response into her mac and moved on. Five days later an email comes in from another team lead asking how do they use the feature that allows applicants to attach existing profiles.

Since then am much wiser and would almost certainly never commit to a schedule just like that. Yet this scenario plays out in software agencies everyday. The client, the manager and sometimes fellow developers expect an immediate answer in days of when something can get completed. Giving an off the cuff answer to this kinds of queries is usually a bad idea.

In this entry, we will explore why this type of estimation is cancer to your project planning.

You will not remember to factor in less visible activities

Asked to give an estimate, most developers will think of the classes, methods, services and other such technical considerations. What will not immediately bubble up will be things like: Time supporting the current version, meetings, organizational commitments, emails etc.

That is, unless you keep a detailed log of all activities, you are highly likely to forget the more mundane ones. The problem is that even mundane activities take time to get done.

It would be wise to keep in mind H.L Mencken quip

    For every complex question. There is an answer that is simple elegant and wrong

With this then it is more important to ensure that the estimate you give is correct rather than it was given quickly.

Commitments are made to others

Unfortunately, many of us in the industry do not differentiate between estimates and commitments. By this I mean that whenever you say “I estimate that this task will take 3 days”, what the client hears is “I commit to getting this done in 3 days”.

In the entry Estimates, Targets and Commitments I delve more into the difference between the terms and how mixing them up comes back to bite you.

For this entry it suffices to say that the estimates you give as a developer feed into the plans of the rest organization. With so much weight, the opinion of how much time a task should take should not be done in a rushed manner.

Devaluation of the proper process

Typically, the estimation process is three step:

  1. Establish the size of the user story relative to other stories
  2. Establish how long it takes to complete one story
  3. Schedule the stories into sprints

Compared to just spitting out the first value that comes to your mind, this process takes a heck more time.

Yet this method still remains one of the most effective ways of arriving at dependable estimates. When you shortcut the process you end up unconsciously training the client to expect immediate estimates. This then ties you into a vicious cycle where your estimates are wrong, so the client asks for another set of estimates, which you then give off the cuff and they end up being wrong and the process repeats ad nauseum.

Accuracy goes off the window

By giving a precise value such as “this will take 3 days” you create the illusion of certainty. In reality, accuracy and precision do not always go together. Eg if I tell you “This will take me a week or so to complete” vs “This will take 5 days to complete”. Which one do you think is more precise? What about more accurate? Obviously the first one is less precise but will likely turn out to be true, the second one is more precise but if anything comes up and I no longer can deliver in five days then the estimate is no longer accurate.

With this in mind, you should then remember that estimates for user stories are given as a triangulation of the estimate given for other similar stories. This eliminates the need to be extremely precise since the estimates are relative.

Traditionally, it has been advised that you give a range such as “This will take 3-5 days to complete”. Personally I doubt the effectiveness of this strategy. Chiefly because being humans, we tend to conveniently forget values we don’t like. So you tell your project manager this will take 3-5 days but what they communicate to the client is that it will take 3 days. That is the range gets collapsed to a single value somewhere in the communication chain.

Do you give off the cuff estimates in your own organisation? Talk to me in the comment section below or on my twitter @jchex