Category Archives: agile

Minimum viable product and User Stories

Once you have your team, it’s time to turn your attention to the product.

You may want to build a site that displays pictures of cats, for example. This is a simple enough brief, but where should you start? This is where the Minimum Viable Product (MVP) comes in.

You want to put your site up as quickly as possible. Every minute your site is not live, you’re losing potential customers. We need to take the concept and boil it down to it’s most basic useful implementation and focus just on that. Once it’s live we can start to see people come through and we can learn what they want while we continue development (which, apart from generating revenue, is the second most important use of customers).

The User Story

So what’s our MVP for the cat picture site? What does our user want and how does that translate to development? This is where we turn the project on it’s head; we no longer have to consider why we are building the product, but rather ask the question “what does the user want to do with it?”.

As a user I want to be able to see pictures of cats so a can feel warm and fuzzy.

This is the basic format for a user story. It has a protagonist, in this case the  user but it could equally be another type of consumer of the site such as an administrator or even occasionally a developer. It also has a goal and a driver behind that goal. The goal could be psychological as in this case, or practical and it always fulfils a need – there’s very little point developing for nice-to-haves.

In order to fulfil our MVP we don’t need any design, we don’t need extra pages, we don’t need any data from the back end. We just need a single Web page that displays cat images.

Once we understand this, we would usually start to further distill this into developable tasks. Because I’d like to dedicate the next blog post to task breakdown, we’ll keep it simple. Our front end developer sets to work and adds cat images to a web page.

It probably looks a little like this:

Cat Site v.1

Sure, it’s not pretty, but now you can release your site to the world, safe in the knowledge that people can look at cats.

Next up: Task breakdown.

Working as a team to deliver software

Team organisation

In order to build a successful web app, you need to have team representation from every discipline. These disciplines are:

  • Information Architecture
  • Design
  • Back end
  • Front end
  • QA

This list is largely representative of the functions needed to produce any other piece of software (mobile app, desktop app, game), which can be augmented or substituted with additional members as need be.

Incidentally, this order is approximately the order in which you need to tackle a piece of functionality in order to complete it.

The importance of role separation – even in small teams

While it’s possible to have a single person be responsible for more than one of these disciplines, I would still recommend they are treated as separate and approached as different tasks. This prevents you from needlessly switching between multiple jobs, damaging your efficiency. It also means you’re 100% focussed on the solution at hand, which should yield better results.

By breaking work down into component disciplines, you can start to simplify the load. This prevents generating or tackling too much work at once (which is harder to then analyse and digest by the team). You can also start to assign jobs to different people. By splitting the job out between multiple team members we can increase our pace, but at the expense of continuity of information. This sounds obvious, but if you’ve spent a year working on a project in a closed room on your own, then you really need to stop and readjust your way of thinking to incorporate the concept of ‘team’.

The process I’m trying to outline here is designed to minimise the extra overhead incurred from using multiple team members on a project.


Aside from actually delivering your software, continuity of information should be the top priority for your team.

Your team is dependent on all other members in order to deliver (as the array of disciplines should indicate; you can’t do front end without design, for example). Equally, should a team member fall sick or leave the project, then the others will know what they were working on and be at least able to account for what part of the puzzle is missing (even if they can’t step in to their role personally, they could impart knowledge to a new-joiner).

Ideally, your team should communicate on a daily basis in a stand-up or scrum. In these meetings each member says 3 things :
– what they did yesterday
– what they’re doing today
– any issues, impediments or blockers to what they’re doing that another team member may be able to alleviate.

Talentomic is being co-developed by myself and another developer based in Helsinki, which makes it a great example of the need for constant communication. As progress happens around other commitments and work, we both have a different pace of working – I may have 4 hours free in a given week, whereas my counterpart may have 30. It’s thus unproductive for him to be waiting for me to complete something, or if he is dependent on me to deliver something, knowing it’s precise status helps plan his work and keep the project moving.

Once your team knows who they are and what they’re trying to achieve, it’s time to start breaking down the project into bite-size chunks, which will be the subject of my next post.

Planning and delivery for medium sized software projects

I intend to put together a series of posts over the next few weeks on my learnings and views on delivering software. I will be using concepts mostly pillaged from others at the various places I’ve been working over the last few years who are or claim to be ‘agile working environments’ as well as from things read online (sources I’m very unlikely to remember, so please excuse me).

This will largely be advice garnered from and intended for practical application – there are many tomes dedicated to theoretical agile delivery, but this should act as a good beginner’s guide and provide templates that can been lifted onto your own software challenges.

By ‘software’, I mean any form of incrementally deliverable product. I will be predominately concerned with Web apps, but with practices that could as easily be used for mobile apps, installable computer programs (providing you have functionality to update them) and games.

At Ding Digital we’re in the process of creating a talent management application called Talentomic. I will pepper this guide with working examples from this work to provide context which I will also be able to show in the various stages of its delivery.

The first section is all about The Team and can be found by going to the next post.