5 tips for an awesome demo day

Aah! demo day. Finally, the day where the developers get to shine. This is the moment everyone has been waiting for, the fruit of months of labour and thousands of dollars.

But it never really works up to a rosy picture now does it? For me at least it never was.

The pattern was eerily similar:

    4 weeks to demo: App is mostly ready just this two features to knock off
    3 weeks to demo: Critical design flaw found that means rewriting a huge chunk of work to accomodate new features
    2 week to demo: Work around found, tests no longer run. That is ok the app still works
    1 week to demo: Panic all around, bugs seem to be popping every day at an increasing day
    0.5 weeks to demo: The *Whack-a-bug* is proving insurmountable. Even previously working features have started to disintegrate
    2 days to demo: Decision is made to postpone any new code. From now on anything that doesn't work we mock. We can make it work later.
    1 day to demo: Barely passable app, what doesn't work has been mocked up. The client can't possibly know
    Demo day: The client notices some design flaws but thinks its kinda ok
    1 week after demo: App has failed terribly in production. The client's customers are fielding complaints about the product
    3 weeks after demo: The application is pulled off the market 

Thankfully those days are no longer with us. If you still face this challenges, then read on.

What I present here is a series of 5 guidelines that when applied are guaranteed to make your demo day much smoother.

Work on a definition of done

It is surprising how many teams don’t have a definition of done. It is easy to assume that once a feature is done, it will be self-evident to all parties concerned. Assumptions pave the way to demo hell.

The developer team and the client should agree on a definition of done. A sample definition would compose of the following checklist:

  1. Coded
  2. Tested
  3. Documented
  4. Usable
  5. Running on target device

Appropriate platform

Emulators are everywhere. They are fast reliable and give you a way to quickly iterate over your work without ever leaving your sweet desktop environment. They, however, hide a dirty secret. Your PC is performing at a rate that most servers or mobile phones can not match. So unless you are building a desktop app, the feedback you are getting is just lies.

Compile the application and run it on a range of phones, deploy the app to a 1GB server. In short, do anything and everything to test your app regularly on the environment it will be expected to run in production.

During the demo, ensure the app is running on this platform as well.

Don’t fake it

If a feature is not ready, don’t fake it. You may avert the client’s wrath for a while but trust me your reputation is worth more than a few uncomfortable moments. In fact, if you communicate the schedule slip in time, you just may get more time on the project or otherwise agree on a mutually satisfying solution.

This, of course, goes all the way through to internal demos. There is no half way done. Only done and not done.

Just another day

If you have to go out of your way or dramatically change how you work on the lead up to the big day, then you have already lost. People who work too hard make too many mistakes. Progress should be consistent and maintainable throughout the duration of the project.

The presentation itself should be informal. With the team and the client discussing what has been presented. Try to have the client physically there for the demo if possible. If not, use the best AV devices you can get to simulate co-location.

Timebox it

All good things must come to an end. Have a strict timebox for the presentation. Informal here does not mean disorganized. There should be a structure to the meeting. Something like.

  1. Introduction by scrum master
  2. Reiteration of the sprint goal
  3. Allocation of time slot for presentation of various features
  4. Allocation of time for feedback on presented features
  5. Approval by client

How do you run your own demos? Tell me in the comment section below or on my twitter @jchex


Planning for risk

In past entries I have talked about risk Hidden risks to project success and even delved deeper into specifics of developer risks and financial risks

If we take a step back and look at the concept of risk as anything that could potentially cause your project to fail. Then risks to your project are much more than I have ever covered and are nuanced to your particular situation. If you tried to cover all potential risks then you would end up spending more resources that is possibly worth.

In this entry we will be looking at the concept of a risk assessment matrix.

A risk assessment matrix is an impact vs likelihood matrix representing the various risks that are on your project. The three by three matrix helps you visualize the overrall risk profile of your project and show you where you should focus your efforts.

The matrix

You can make a bigger copy of that particular matrix or even use it a doc.

Risks are arranged with increasing impact on the y axis up. They are placed with increased chances of happening to the x axis.

You will note the measure of likelihood and impact are relative to each other.

Example of a filled out matrix below:

Mitigating the risk

Now that we have the risks listed out in a way that we can easily visualize, its now time for us to jump into action.

Level 1 risk

This should appear as an item on your next iteration.

You should do anything within your power to mitigate this risk as soon as possible.

In the example above we had feature creep. So you may want to for example have the client sign off the user stories to be built and have the agreement in writing. This action would push down the risk on the likelihood scale.

Level 2 risk

This risks don’t require urgent action. However you should dedicate some time to coming up with a mitigation strategy in case the risk does materialize.

In the example, we had developer gold plating. It may not make much sense to over invest in making sure the developers don’t gold plate. A simple practise like daily standup can help you control the risk.

Level 3 risk

Risks on this category present an avenue to exercise the mantra, what you don’t do is just as important as what you do.

Beyond basic monitoring, you need not invest much in this risks. You only need to watch out for when there level escalates.

In our example we had developer is poached. Since we take good care of our developers we know this will not happen and even if it does happen the contract with them stipulates a 30 day notice.

How do you control risks on your projects? Tell us on the comment section below or on my twitter @ jchex


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.