Engaging sprint planning sessions


What is the shortest sprint planning meeting you have ever walked into?

For me, it has to be one that went like this:

    Developer 1: Ok so let's keep this short so that we can get back to work
    Developer 2: I agree, this place has way too many meetings this days
    Developer 1: (Laughs) True true
    Developer 1: So you will do the backend I do the frontend
    Developer 2: As we always do
    Developer 1: Awesome meeting over!
    Chencha : But what will be done in the sprint?
    Developer 2: What is on the TOR doc

At that moment I thought they were playing a prank at my expense. Sadly, they weren’t. As it turns out they did not know what to discuss on this particular meeting.

On this entry I will be sharing some of the discussion points that I have felt led to a more lively sprint planning session.

Break down requirements to user stories

Unless you are one of the lucky few who work with clients who understand agile, you are probably stuck with a legally enforceable TOR. Still no need to despair, we can still recover.

Use this time for you and your team to actually break down the massive document to user stories. Pin the stories on the board or trello. Depending on what your team usually uses to visualize work.

Use planning poker

Planning poker is a technique where individual developers give their estimate by first writing it down in private and showing it to the rest of the team concurrently. This ensures the estimators don’t influence each other.

Once the estimates are made, don’t just stop there. Ask the person with the highest or lowest estimate why they think the item is of that size. This practise should elicit some discussion within the group.

Establish objectives

In the 80’s, professor Noriaki Kano came up with a model that classified customers preferences. Basically there are features that the customer just can’t do without and there are some that the customer wouldn’t know they want until you show them. You must weigh the features you aim to develop on this scale.

Have the team discuss the project and distill the objectives of the project.

Once this is done, the project will achieve efficiency advantage in the trade-offs that they will inevitably have to make.

Break down user stories into tasks

User stories are rarely small enough to code. This meeting presents a great opportunity to discuss the tasks that make up a user story.

Take the case of this user story.

    As a customer
    I want to search the store
    So that I can see what is available

Now that story can be broken down to

  1. Install elastic search
  2. Connect elastic search to laravel
  3. Write endpoint logic for the search term
  4. Return response as json
  5. Write html to display the results

Developers can deliberate and come up with the most exhaustive list of tasks possible.

Determine velocity to use

The general rule of thumb is to use the last iterations achieved velocity for this sprint. This meeting presents an opportunity to review the rule and see if it makes sense in the current context.

Respect the Timebox

The purpose of this entry was to discuss how to make your meeting more lively. However if you push it too far, the team may not look forward to the next meeting.

Ensure to state how long the meeting will last before it starts and respect that timebox, no matter how fun or engaging the meeting becomes.

How do you liven up your own meetings? Talk to me on the comment section below or on my twitter @jchex https://twitter.com/jchex


Selecting the best vendor for your product


How would you like to shave 20% of your development time? How about 80%?

As Peter Drucker once put it:

    There is nothing quite so useless as doing with great efficiency something that should not be done at all

Vendors and the tools they produce help us avoid coding up features that could be more cheaply bought.

They come in all shapes and sizes including:

  1. Open source libraries (apt-get, bower install, composer install, pip install etc)
  2. API services (Apigility, NLP tools, Lorem generator etc)
  3. Cloud services (Firebase, Queueing , Realtime push etc)
  4. Frameworks (Django, Laravel, Angular etc)

And many more.

Considering how crucial all this vendors will be to your application and by extension your business. How do you choose which ones to use?

In this entry we look at some of the considerations to make when choosing a vendor.

How long has the vendor existed?

Experience is a harsh teacher but it teaches true. You want the builders of your tools to have undergone the test of time. Being a new product, your application is guaranteed to be teeming with bugs. You don’t want to ever be unsure if the bugs are in your code or the vendor’s code. Having a mature tool means that the vendor’s bugs have mostly been taken care of so now you can worry about your own bugs.

You should of course ensure that their experience has informed their iterations. Look at the release notes for signs of improvements over the various versions.

Are they committed?

For commercial products, it should be evident that the product they are peddling is an important one in their portfolio. Peripheral products suffer the risk of abandonment on short or no notice at all.

For open source projects, look out for a core team of long term contributors. You can bet this contributors have given their soul to the project and are not likely to give up on it now.

What would happen if vendor abandons it?

A lot of projects would wither and die if the project sponsor abandoned it. Some projects however have managed to attract a community around it and some even have an entire ecosystem.

The second kind of project is the one you want to use on your development. You can be sure even if the vendor abandons it, there will be a line of others waiting to support it.

Can you maintain the project?

If the tool is critical to your product, then you must consider your own ability to support it. In addition to the risk of abandonment, you also face the risk of the vendor evolving the product such that it no longer matches your priorities. If that does happen you must have carried out due diligence to ensure that:

  • The source code is available to you
  • The code quality is of an acceptable standard
  • You have personnel with the requisite skills

How do you decide which vendor to use for your own product? Talk to me on the comment section below or on my twitter @ jchex


Controlling developer risk

Managing software projects is not easy work, but once every while you do get a break. As the gods would have it, this was my day. Everything was going swimmingly well, we just had a couple of bugs to close before the client demo next week. The developer on the team was a solid engineer, his code quality said so.

On this particular day we were having our final review. 5 minutes into it, the developer is not yet in, no worries. 15 minutes later he is still not in, try to call him he doesn’t pick up. We suspend the meeting to the afternoon in the hopes that he will show up. Afternoon comes nothing, evening nothing. The developer goes on to disappear for the entire week, picking up only once to say “I will call you back”. The call never came.

In a previous entry I talked about Hidden risks to project success. Today I will expound on the biggest risk of all, human failure.

Paradoxical relationship between money and motivation

Developers for most part are self motivated individuals. In your hiring process you maybe shocked to find someone who has written multiple open source software, put products in the market and contributed to their community.

It easy to conclude that if they could do all that for free, then imagine what more they could do for money!

Unfortunately this conclusion is wrong. Somehow when you pay the dev to do the work they were previously happy to do for free, the magic disappears. I wish I had a cookie cutter solution for this phenomena. Still I have learnt if you can somehow find a way to give authority back to the devs, the results can be amazing.

Here of course I assume you are paying your developers reasonable rates.

Ineffective management

The field of project management has matured and is now a degree course. As it turns out, your PMP certification does nothing to prepare you to manage a software project.

It is said you can learn more from one failed software project than an entire lifetime in any other field. Software presents challenges that no other project presents. If I had to narrow it down to just one factor. I would have to say it’s the fact that the design is the product. To understand the gravity of this concept, imagine a building project. First the architect draws up the plan, then the builders get to it and get the building done. If the design is successful then future builders can reuse the design to build a new building. In short the work can now move to refining the process by which design is converted to product.

In software once the code is written the only work to be done is to compile it. Every new piece of software represents new design. The elements that can be reused are at best libraries.

This means as the project manager you have to deal with design problems and risks that are novel each and every time.

Unless the project manager understands this fundamental concept, they will continue with hacks that worked in the past such as:

  • Adding more people to the project late to get it done faster
  • Overly detailed project plans featuring Gantt charts, CPMs that are accurate to the hour
  • Encourage Code like hell mentality

This tactics slowly kill the project from the inside out.


There is no single factor that would give you assurance of the quality of your hire.

  • Not their contribution to open source
  • Not glowing reviews from past clients
  • Not even a previously successful project!

The reality is you will eventually make a terrible hire. When that does happen the results can be disastrous. You will see it in poor designs, increased rework and communication break down.

Hiring them in the first place can be forgiven, what can not be forgiven is keeping them on the team. The rest of the team will degenerate in performance to match the poorest performer, do not assume that the new hire will be the one to catch up.

Ramp up time

When a dev gets into her flow, everything is magic. She merely needs to touch the computer and quality code practically writes itself.

Before this magic moment, there is time they just don’t understand what is going on. This is especially evident when you drop in a dev to an existing project.

It may take a few minutes to understand a concept note, but it takes days or even weeks to grasp the technical requirements that will bring that concept to life. Give your developer the time she needs to acclimatize herself to the project. Factor in that time when planning the project.

What are some of the personnel issues you have run into when running software projects?


Hidden risks to project success


A story is told of a product manager who got a complaint from one of their major clients. The complaint was addressed to the apparent slowness of the app when getting data from the server. As it turns out, the PM knew a code ninja from back in the day. The PM had heard that the ninja has been working on a customized SQL engine that enhanced query performance on products such as his by a magnitude and in some cases even more.

So he had the ninja brought in to demo her invention. The new library proved true and the PM promptly had the developers implement the library on a hotfix that was then released to the major clients.

Once the new app got into production, it’s weaknesses started showing, for some reason the library was updating wrong records. The PMs company got sued, he tried to pass on the suit to the developer but the developer promptly pointed to the copyleft. The company ended up losing millions in the suit and even more from a tarnished reputation.

In today’s entry we will be looking at some basic guidelines to avoid such mistakes when making design decisions.

Fighting complexity with complexity

Software projects are incredibly complex creations. It is tempting to assume that the answer to creating this complex products lies in crafting complex designs. You would be wrong.

The practise of XP explicitly admonishes this belief in their credo.

    I have been surprised many times by how efficient a simple design can be. Simple designs often out perform highly complex yet theoretically optimized designs.

John Gall puts it even better.

    A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.

Sometimes a monolithic app is the best answer. Your job as the developer is to deliver business value. Engineering skills are worthless if they can not generate economic value.

Simple designs require deep understanding of the problem you are trying to solve. This is hard work, but worth it.

No design

It is at times easy to confuse the concept of simple design with no design at all.

Doing a project with no design means you accrue a ton of technical debt in the process. As we have discussed in How you pay for technical debt when the debt falls due, your project will not stand.

Lower level languages

Very few developments in the field of software engineering have been able to provide a 10* gain in productivity.

F.Brooks famously stated:

    There is no single development in either technology or management technique which by itself promises even one order of magnitude of improvement within a decade in productivity, in reliability, In simplicity.

This statement was said in 1986. And it held true. But before then the said improvement was actually achieved when compilers were invented. Suddenly developers no longer had to care about machine code, only the business logic that they wrote.

From this era, the field has advanced greatly with successive languages abstracting the machine even more. Modern day languages have syntax that more closely resembles business parlance than scientific jargon.

Yet there are developers out there who want to take us back to the old days. Claims are made of the speed of lower level languages such as C or even worse assembler languages.

Unless you have a very strong case, avoid this languages and the developers who insist on using them like the plague.

Unfamiliar processes and tools

Developers are attracted to new shiny tools. That is a fact. Wether its a new IDE, language or even note taker. We love the novel.

Unfortunately all new tools have unknown kinks. It takes time for the product to mature. Obviously if you stuck to only the tools and processes that you are familiar with, you would become obsolete. With that said it is still better to err on the side of mature tools so that your team can focus on the product you are building rather than figuring out if whether the issue you are dealing with is a bug or a feature.

In my experience the above are the design problems that keep on creeping up. Tell me about your own experience on my twitter @jchex or on the comment section below.