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


Negotiating tight schedules

I follow very few TV programs. One that I happen to love is called game of thrones.

In one of the episodes, one of the characters demonstrates power in a brute way. Jeremy Sadler gives a great summary of the scene EXAMINATION OF A SCENE: CERSEI AND LITTLEFINGER

As developers, we sometimes come into direct contact of this kind with corporate politics. Not being used to dealing with politics, we usually end up feeling hopelessly trapped like little finger.

In my last entry, Dangers of underscoping I highlighted the importance of pushing back on unrealistic schedules. Thankfully most clients don’t walk around with armed guards. Even better, the client wants their project to be successful. Being the technical one, you should be able to provide some solutions to the schedule dilemma.

For this entry, we are going to look at some of the more effective ways to ease schedule pressure without offending the powers that be.

You ain’t gonna need it

Pareto law, otherwise known as the 80/20 rule states that 80% of the effects are caused by 20% of the factors. This is just as true in software Chaos report 2015.

A good number of the features that the client is requesting, they will probably never need it. Telling them so is however not likely to be an effective strategy. What would be an effective strategy is suggesting that an MVP be built first.

The MVP would then inform the next work to be done. This is good for the development team because now they have less work to do with the available schedule. It is also good for the client team because they get their product to their customers faster and at a cheaper rate.

Highlight time consuming features

Believe it or not, it may not be as obvious to the client that features that they are requesting take inordinate amount of time. You may find for example that initiating an automated refund policy consumes four weeks of development time, but only a minute to explain the functionality.

Based on your estimations, you can tell the client how much it actually costs in terms of development time to roll out the various features. They may then chose to drop time consuming features that have little value to the project.

Buy don’t build

For all the vendor software available in the market, you maybe surprised at how much needless development actually goes on.

Sometimes a bespoke solution that would take weeks or even months to develop could be easily replaced with a generic one that takes minutes to install. Sure it may not be up to the quality that you expect but if its not core to the clients business then sometimes just enough is all you need.

For projects that are really squeezed for time, I would go so far as to recommend that you build the project in a way that aligns with existing third party tools.

Bigger team

If you are not yet deep into the project, more developers can make the project go faster. This can be an option for clients who don’t care about the budget as much as they care about timeliness.

This option is a dangerous one for new products. This is because the scope may not be clear and bigger team means higher communication overhead.

Motivate the team

Energy acts as an accelerator of productivity. If all else has failed and now you must work with a tight deadline, then it’s time to sufficiently psyche up your developers.

A trip to the coast, promise of new devices or even just their own private space. This external rewards can prove to be the elixir that burns all the stories in half the time.

Be warned, this strategy will not suffice over the long term. Eventually burn out catches up even to the most energetic of us.

How do you negotiate tight deadlines? Talk to me on my twitter @jchex or in the comment section below.


Did you build the right product?

The day when the product changes hands from the developers to the clients is seldom an easy day.

That is the day that a random integration issue comes up, the servers start misbehaving and what otherwise worked yesterday suddenly doesn’t work today! The developers don’t particularly help the situation. The standard response is usually.

    It works in my machine

The client is no better, sensing that they may have traded in their hard earned dollars for a barely functional app, emotions are guaranteed to run raw as trust goes down the drain.

In this entry, we are going to be looking at this phenomena and coming up with ways of mitigating and maybe even making this day a good day.

To start off, it’s important to understand the difference between a product that has been built right and the right product. By far the biggest risk to any development process is building the right product. If you miss out on this then the client will be disappointed no matter how efficient your process.

So how do you make sure you are building the right product? It boils down to ensuring you are building a product that solves a user problem. That is you validate the product. This lies mostly in the domain of UXers. Still, we will mention some of the basics.

How do we make sure we are building the product right? This is a matter of process. Thankfully Scrum takes care of it. In this entry, we will talk about the meetings in scrum and how they facilitate the verification of the product



Sometimes old really is gold. User surveys still remain one of the most effective and affordable ways of getting user feedback.

In your survey you want to find out the following:

  1. What is the problem the users are facing?
  2. Do they like the feature proposed to solve the problem?
  3. Would they be OK if the feature did not exist in the product?

The first question helps you understand if there is a valid problem you are solving. The second one helps assess the desirability of the feature. You don’t want to unnecessarily bloat your application and waste valuable developer time. The third question helps you assess if the feature is a pleaser or a must have. For example, if the results suggest that the users don’t particularly desire the feature but would be severely displeased if the feature was not there, then you have a must have. If however they really desire the feature but don’t care much if it’s not there then it is a pleaser. A lot of insight is gained this way.

User stories

User stories are a way of expressing requirements from the point of the user. See Invest in user stories By expressing the requirements in this format. It is easier for the developers who will be building out the requirement to have clarity on the purpose of it and to make the right tradeoffs.

For example a requirement expressed as “include option to send password reset link via email”” vs “As a user I want to be able to reset my password so that I can recover my account” means that the developer working on the story can be able to say provide fingerprint password reset for capable devices. An option that would not be considered in the first case but that maybe more valuable.

Also by clarifying the need, the team is forced to elucidate on why the requirement even exists in the first place.

Remove abstractions

We rarely consider the layer of abstraction that words create. Words gain meaning from cultural context. In today’s global economy, it is likely the development team and the client have different backgrounds. So when the client says build me a house she may mean she wants this

The developer’s mental model of a house maybe this

Both, of course, are right. They are all houses!

To get over this limitation, let the client sketch out what they want the app to look like. No artistic skill required. Even a rough sketch can convey an idea better than the most eloquent prose.


Planning sessions

Clients are generally not techies. It would be easy to assume that they would not add much value to planning sessions. This assumption is wrong. While the client may not know the tasks that go into getting their stories built out, they do know the value of the stories. They thus are in charge of prioritizing them.

As the discussion on how the stories will be broken down into tasks and the effort required to build the story becomes more apparent. The client’s estimation of the stories worth may vary going either up or in some cases going down to the point where a decision is made not to build it all.

Also, the work of breaking down the story reveals the developers understanding of the story, having the client there provides an avenue for them to confirm if what they want was communicated.

Development usually happens in a natural flow, eg you first build a registration platform before a user statistics platform. This order may not be clear for developers who are not part of the domain that the client works in. By having the client in your iteration planning meeting, you get this feedback immediately.


It is tempting to want to only show the client a finished and polished product. Doing this will, however, put you in a position where any feedback that was given is expensive to incorporate back to the product.

Instead, consider “demoing” incomplete versions of the application. As long as you manage expectations, you can get very valuable feedback quite early in the process.


Despite being the most effective and easiest to implement, the daily standup faces the most resistance to adoption. A regular and frequent sync session ensure that the developers are aware of what others are working on and thus adapt accordingly.

This session also provides an avenue for integration issues to be discussed and ironed out while they are still fresh in the developer’s minds.

There we go. By implementing the practices above, I have been able to experience better demo days than was previously possible.

How do you know if you built the right product? Talk to me on my twitter @jchex or in the comment section below.


Estimating with limited information

Best client ever. You have gone through all the steps on the elicitation stage. You have worked on the epics broken them down properly and now have a healthy backlog of user stories that is representative of the app you will be building and now you can work on estimates. Awesome right?

Yes that would actually be awesome except in reality it just never happens. More often than not the client will want at least a ball park figure from the initial meeting when all you have is just a story.

The ideal way would be to reject this option and insist on a proper elicitation phase. Unfortunately that may not be practical. Fortunately there is a way of still getting to an estimate albeit a rough one.

Introducing function points.

Almost all business applications can be decomposed to the following major categories.


Includes the ways available to the user to feed data to the application. For web applications this would be forms, for mobile applications this would be dialog boxes, controls etc.

Depending on the application, exotic options maybe available such as finger tracking. They would still fall under this category


What the system displays back to the user.

Most common options would be:

  • Tables
  • Graphs
  • Messages
  • Reports

The only requirement is that the output be targeted at a human consumer.


Very similar to outputs with the distinctions that inquiries return results in raw format. This can be consumed by humans or machines.

The distinction is important because you rarely have to write a lot of code to get inquiries going.

Most common examples would include:

  • Database queries
  • Simple search
  • API GET to a simple resource

Logical Computations

Would include major manipulation to the data that is to be done by the system. Unless your system is purely CRUD, you will need this layer as the value add for your application.

Most common examples would include:

  • Run payroll for all employees
  • Calculate shortest distance between two points
  • Convert file types


In the connected world your app probably works with multiple other services to bring value to the user. You need to take this into account when doing your estimates. Examples of such would be:

  • Social login
  • Connection real time technlogies. eg Pusher, Firebase
  • Remote DBs eg Big Query
  • Remote file systems eg Dropbox, S3


Not all items in the categories would be equal in weight. As such you need to apply certain multipliers to the items to equalize them. Based on empirical analysis of software projects by Casper Jones in the book Applied Software Measurement: Global Analysis of Productivity and Quality. We have a reasonable basis for such weights.

Note in our nomenclature we classify Logical Internal Files as Logical Computations and Logical Interface Files as Integrations.


Suppose now you have come from the client meeting and you managed to pick up they would need an authentication system with Google+ and Twitter login. How would you go about that?

Starting with the categories highlighted above as a ticker list you would come up with something like this.

Epics are the major areas you we’re able to pick out. The categories are as discussed above. The complexity is a subjective opinion of the item to be built. For example in my case I consider complexity of login form in category Inputs to be low but consider a registration page in category Inputs to be high.

From this data we can now calculate the number of points based on Casper Jones multipliers.

What do the points mean?

The points have given you a size estimate but not a effort estimate. To get a effort estimate in developer hours you need to look back at previous projects to see how points map to time taken for individual teams or developers.

Let us assume that looking at previous data you note that the relation between developer hours and points for your team looks like this

    developer hours = points * 0.5

That is it takes a developer half an hour to complete a point.


    developer hours = 46 * 0.5 = 23

You can thus estimate that your developers will take 23 hours to complete the user authentication.

This estimation technique requires you to keep metrics on past projects but also enables you to very quickly compute estimates once you have a solid record of past performance.

The sheet used to do the computations can be found here.

Have you ever used point estimation on your own projects tell us in the comment section below.


5 ways to keep your client in the loop

Software is expensive to develop. We all know that and are more than happy to charge our clients our true worth. For worthy clients the amount is not the issue, the project will likely net them multiples of whatever you charge.

Imagine yourself as a businessperson running your own bakery. You sell cakes to the local neighbourhood residents. You meet this awesome developer who promises you that they can boost your business by 100* if only you could enable customers to order online. This sounds like a good idea and you are all in, you invest 5 month income worth of your business to building the product.

A timeline of 8 months is agreed, contracts are signed, deposits are paid everyone is happy.

One month down the line you walk by the developers office to see the progress done so far. The developer tells you that they still are setting things up but are fully confident they will make the deadline.

3 months after commencement you once more walk to the developers office and you find that they have not started yet but claim their machines are all setup. You are told that there was sufficient slack allowed in the schedule and there is still so much more time to get work done. You are a bit apprehensive but you comfort yourself, after all this guys are professionals, surely they must be.

5 months later there is now some progress and they call you to their office. Eagerly you wait as they open up the first page of your brand new web app which looks freaking fantastic! You love the landing page, the color scheme is amazing, truly reflects the essence of your business. You try to click the link to login and are promptly stopped from doing so. As it turns out the page you are looking at is the only thing that has been developed.

Our story ends here, you see it does not matter even if the developer somehow delivers the project in the three months remaining, the project is already failure. The obvious reason is that the product will not have taken the clients feedback into consideration. Even more insidious, the developer forgot a basic tenet of software engineering.

    Perception of slow development can affect your project as much as the reality of it.

You see, it is part of the developers job to provide their client with steady signs of progress.

So how could the developer have gone about this task? That is what this entry is all about.

Standardized requirements and checkoff

In a previous entry I talked about Investing in user stories. A side benefit of using user stories is that they easily avail themselves to be broken down into developer tasks.

Developer tasks are actionable items to be carried out by developers.

By breaking down the project into such tasks. Progress can be made visible as tasks are checked of and then entire user stories are marked as done.

Status meetings

Now I hate meetings as much as the next guy. But truth is that the most effective form of communication happens face to face. This meetings don’t have to be long, they just need to be regular.

Scrum practitioners have mastered the art. Their meetings are called daily standups and last a maximum of 15 minutes. All team members answer the three questions:

  1. What did you do yesterday
  2. What will you do today
  3. Are there any blockers

Status reports

Ok maybe the idea of regular meetings is too hard to swallow, what about regular reports? The basic idea is the same as meeting but now people submit their progress via email or chat.

This can be more convenient since a record exists and the reports can be done asynchronously.

Milestone reviews

As a developer, you should only write enough code for the client to review. At project onset, you can decide this review periods and set them as milestones.

Bonus points if you can tie compensation to this events.

By having clear milestones and reviews, the client is kept in the loop and their feedback is integrated on future iterations.

Walking around

Yes I know developers are professionals and don’t need someone watching over them. But this has nothing to do with the developers. By giving the client a chance to come to your office and basically walk around seeing your scrum board, burn charts, design diagrams etc. They get pleasant warm feelings about the progress of their project.

I hope it’s clear to everyone why its important for clients to have this feeling.

How do you keep your own clients in the loop? Tell us in the comment section below.


Invest in user stories

Meet Timmy. Timmy is a freelance developer with several years of experience. He has previously worked on small to medium size projects and has a good feeling about his ability to execute.

Meet Sarah. Sarah is head of sales at BigCo Consulting. Since she started at the organization as an intern, they have grown leaps and bounds. She now runs a team of ten people but managing communications within them is becoming unwieldy. She has at best, a vague idea of how tasks she is assigning are getting completed and in what time.

Sarah has heard of the good work that Timmy did for her friend. She believes that her organization would benefit a lot from his services. Seems everyone is making it big in tech this days and she wants in on it.

A kickoff meeting is set off between Sarah and Timmy. Sarah explains that she needs a system to manage her workers more effectively. They discuss about potential features on the product and come up with a list that Timmy is to develop.

  1. Secure authentication
  2. Task management
  3. Accessible from anywhere

This feature list seems good and Timmy comes up with a time estimate and tells Sarah what she needs to pay him. A contract is signed and they both leave the table happy.

One month later Timmy is back with the first MVP done. In the MVP the app enables Sarah to assign tasks to her staff but is still unsatisfied with the product. She can’t really pinpoint it but she doesn’t feel that the app will be particularly useful especially because she could have just as well sent out an email to the team member with the same task.

Sarah decommissions the app having only paid the deposit and leaves the table thoroughly dissatisfied. Timmy feels the deposit paid was barely enough to cover the work done and loses a potential referee for his work. What went wrong?

The curse of knowledge

KRS One has a lot to teach us in the software world. Everyone perceives the world from the prism of their personal experiences. Sarah and Timmy come from vastly different worlds. In Sarah’s mind she saw that she had properly communicated her intent, she assumed meaning to her words were built from the same pool as Timmy’s. Timmy assumed the same.

Unfortunately whilst Sarah was thinking of automating her existing process, Timmy was imagining all the bells and whistles he could build on top of her task list program.

Is there a way out of this conundrum?

The bad news is that there isn’t. The good news though is that we can mitigate it.

User stories

A user story is tool used to capture a description of a software feature from the users perspective.

A good user story outlines specific software feature while keeping all the requirement in a consistent format.

They are easy to write, read, evaluate and dare I say fun.

A user story comes in the format:

    As a ______
    I want to ______
    So that ______

User stories come with goodies that would have saved Timmy and his client from the situation they found themselves.

The goodies I speak of are the characteristics that all good user stories share. They have a convenient Acronym



Good user stories are independent. That is they can be developed separately from each other. By putting the requirements in form of user stories. Sarah would have been able to prioritize the user stories that had the most value to her. This action would have informed Timmy on what Sarah’s actual needs were.


Each user story comes with a non-codable part, the So that _____ bit. That part of the story gives meaning to the requirement. Sarah would have a good platform on which to elucidate not just what she wanted built but why she wanted it built.


Software estimation is hard to get right. You can tell when the leading material on the subject is called Software Estimation: Demystifying the Black Art.

Yet we humans can better estimate smaller components than we can larger ones. User stories enable Timmy to get a more realistic view of how the project is and Sarah to understand the effort required to build her application.


User stories should be small enough to fit on an index card. A side effect of this property is that each story can be developed rather rapidly. The quicker the story is developed the faster the feedback loop between Sarah and Timmy can be closed.


Written in this format, it is fairly easy for Sarah to run the user story through the application to see if it actually meets her expectation (Technically called Acceptance test)

There we go. I am convinced next time, Timmy and Sarah will use user stories to capture their requirements. What about you?


Managing scope creep


I sit down with the client to discuss their requirements. We are both stoked about the project and its potential. The conversation goes into all the nice feature we will build and how the whole world will love us. After, I settle in for the hard work of coding it all.

After several weeks of coding I have something to present and request a meeting to show progress. That is where everything goes down the drain. You see, in the time that I have been working on the code, the client has been thinking of many more features that she could add. Features that would make the product even more awesome! And now that she can see what is presented even more ideas are now flooding her mind.

While I expected a “congratulations now finish this” what I got instead was a “great, now lets change it all and add all this other stuff”!. Negotiations about budget? schedule? She will have none of that. You committed to getting the project done and there is a contract to prove it!

I wish this was an isolated event, but it actually does seem to be the rule in software development. In fact, i would hazard that this is a right of passage for all junior developers looking to change rank to seniors.

The easiest way to deal with this problem would be to resolutely refuse any new changes to requirements and stick to what was originally agreed. Bonus points if you have the requirements in written form.

This strategy unfortunately rarely works and even if it did, it would still be bad practise. The reason is that the client introduces changes not to spite you but to increase the projects business success.

So then what you need to do instead is manage the incoming changes. Below are some strategies to do so.


You will never be able to build everything that the client or even the market wants at one point you need to prioritize.

Start by working with the client to distinguish between the needs and the wants. Then from the list of needs prioritize them into three lists:

  1. Must do
  2. Great to have
  3. Will do if there is time

Ensure you get client buy-in on this lists. Put in a reasonable constraint to the length of list of Must dos and Great to haves. A good number would be something like 30 and 50. For any feature that is added to the must do one feature must be bumped down if the list is full. Same case for the Great to have. The “Will do if there is time”  the list can grow to infinity if you wish so.

Ensure to finish all Must dos before picking features from any other lists.

In this way the client is forced to make a trade off on the requirements for the systems.

Make expectations clear

XP places great values in metaphors. The development team and the client select what would make a great metaphor for the application. An example for a movie recommendation engine would be “Your local movie store attendant who knows all the latest movies and knows your taste”.

A clear metaphor is a great communication tool.

During the requirement phase you want to go beyond what the clients want to why they want it. Remember to consistently ask

  1. Why do you want the product that way?
  2. Why do you need the product to start with?
  3. Why would anyone use this product?

Getting this answers will give you a clearer picture of what is going on in the client’s mind.

Check out this great resource by Simon Sinek

Draw the scope with your client

In the story I started with, I literally went home with just my memory. In actuality what you need to do is have the scope in written or drawn form that both you and the client agree on.

Key to this process is defining a product vision.

A product vision is the long term strategic concept of the ultimate purpose and form of the system. It encompasses everything that the product will do to satisfy a user’s needs.

In 1997 Jeff Bezos practically wrote the playbook for Amazon’s success. If you were the developer building the system you better have read and understood it.

When the change finally comes

So far, we have done everything we could to get the real needs of the clients on paper. But eventually the change request will come, this time we are ready.

First thing to do is to put in the new request on the lists defined during prioritization. This gives visibility to how the new feature/change fits into the overall.

Once this is done and the change is actually on the Must do then we need to estimate the effort required to build the new feature. We can then estimate the implication to available product resources including:

  1. Developer time
  2. Financing for the project
  3. Product quality
  4. Schedule
  5. Chance of eventual success

If after all this it still makes sense to make the change then go right ahead and revise the estimates to reflect the new changes, you just landed yourself a winner!

How do you handle scope creep in your own projects? Tell us in the comment section below.