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.


Tips on managing your backlog

You are just from a specification meeting with your client. With you is a big list of features the client wants to see on the application. Probably its all in your notebook or note taking app. What do you do with it?

Today we shall be discussing some basic techniques on how to properly manage your backlog.

First things first

Note apps we’re simply not designed with engineers in mind. A productivity tool is needed. Trello is one such tool. Simply create a new board, put in every item to be worked on into the tool.

Some candidates for backlog include:

  1. User stories
  2. Work tasks
  3. Areas which you/your team needs to gain competencies in
  4. Major bugs (For ongoing projects)
  5. Tech stories (The invisible work that developers see. An example would be migration scripts)

Involve clients and developers

Once you have your initial backlog list out. Its time to invite the clients and the team to view the items. This ensures everyone is on the same page about what exactly is to be developed.

Encourage as much direct conversation between the client and the developers who will be actively writing the code.

During this stage the client has the chance to prioritize what is important since they understand their business the most. The developers however are in charge of the estimations.

However this does not mean that the parties operate in silos rather the clients should explain why certain items are priorities and the developers should explain why they have given the estimates. This is not a formalized process, casual conversation is expected and encouraged.

Select first features for development

The first features will likely correlate with the top priority features but it will not be an exact match. The first features to be developed should be developed based on criteria listed below:

  1. Customer priority. The most important factor to consider
  2. Time to market: Chose features that can enable the application to be quickly tested by end users. This enables quicker feedback cycles.
  3. Resource utilization: Ensure that everyone on the team has something to work on. Ie if you have a DBA there should be some DB work
  4. Co-dependency: Some features will depend on others, ensure to build the most depended ones first

This is not an exhaustive checklist. Communication with your client and developers should land you on the ideal initial first set.

Break down Epics

Epics are user stories that are too big to implement directly. During meeting with the client, you probably gathered a lot of them. In fact at this stage your backlog is made up almost entirely of Epics.

Now is the time to break them down to smaller stories that you can easily track.

A good rule of thumb is if a user story takes more than 2 hours to develop it’s probably an epic. Assuming developer competency of course.

Focus only on current sprint

While it may at times be tempting to develop features directly from the backlog. Focus only on items on the current sprint. The items here can not be changed by the client and are easily estimate able. Furthermore you will be computing your metrics from the items on the sprint.

Backlog grooming

Anything that is not improving is guaranteed by entropy to be getting worse. The backlog is a living list and needs to be constantly updated to align with the priorities of the users and reality as it unfolds.

How do you manage your own backlog? Tell us in the comment section below.