How to lose your money, time, investors and the market. Vision, goals, and requirements.

Back in time

In the previous article, I introduced Mark, who is an entrepreneur and is working hard on his great startup. He hired a software development company to build his product. After some months of development, he found that developers are not delivering what was promised and finally he stop the collaboration. 

His thought was that chosen supplier was a band of amateurs so he started talking with some other companies and asking them if they can overtake the development, but after some investigation, all of them answered that the code is sloppy and crappy and to be honest the best option is to rewrite it from scratch. Additionally, there is no documentation required to be able to work further on the code.

The first part of the series is available here

Today we will help Mark to figure out what mistakes he did and why his collaboration ended in such a sad way.

 

 

Problem to solve

The first challenge for Mark was a problem he wanted to solve. In software development problem is described by requirements. 

The requirement is a thing that is needed to be solved in a solution. In Mark, case requirements were described in two forms. First were wireframes and later designs which were a 'visualization’ of the desired look of the application. Other form were user stories – a popular way of describing what solution should answer to.

What mistake was made here?

The biggest one was that the whole concept was not well explained to the developers. They didn’t have a good business idea feeling. It caused that their approach was more to deliver lines of code, and not necessarily on solving a problem. 

It’s essential that the whole team involved in a project will have a feeling of the mission – the team is a part of something significant what can have a massive impact on desired users. Mission where everyone knows, understand and feel that this impact is significant to users. 

In this case, it didn’t happen. For developers project was just a collection of user stories prepared by Mark based on some guidelines from the project manager from a software company. 

When Mark prepared them, project manager validated if they are complete, but there was no any phrase to see if these user stories will be enough to deliver a great product according to the vision and be still in a budget. Pushing on a reasonable price was the most significant problem.

Next, a whole team discussed wireframes, user stories and after two calls they decided that they can start with development. 

What worse user stories were not defined well. They were written down as a list of tasks without putting attention on the real value of the user story. So when a user story is valuable? When should we implement ANY user story in our project? The answer is simple:

Only when user story brings some value to the user. This is so simple, but in most of the project it’s missing.

The next problem was that all these discussions were not written down in any form. During these calls, the whole team was digging into details, implementation. No one defined acceptance criteria. This is also an essential thing in software development. Acceptance criteria help to set for everyone involved when a feature is delivered.

So user story answer on question – WHAT we should deliver. 

If a user story is well defined then also answer on question WHY we should implement it at all. However, user story never answers on question WHEN we know hit user story well implemented. Moreover, here is a place for acceptance criteria. They explain precisely on a question WHEN user story is well implemented. 

Lack of acceptance criteria was the main cause of problems in a ping pong phrase. Understanding of this how features should work was very different by stakeholders. As I mentioned they had some discussions three months earlier, but no one remembers it exactly, and what worse it wasn’t written down. 

Well defined acceptance criteria are also beneficial when after development we need to validate if the delivered feature is working as expected. They are for us form of checklists – if the feature is fulfilling each acceptance criteria, then we can be more or less sure that it works as expected.

This technique is also beneficial for testers who are responsible for assuring quality on a proper level in a project. They don’t spend time on figuring out how the application is working, but they have clear guidelines on how we expect that feature is working. It’s much easier for testers to test such a project.

Non-features

The next very important this which wasn’t taken into consideration was no definition of non-technical requirements. Always if you are going to build any solution, you should consider not only how your great application will look like, how logic will work, but also you should think about such requirements like the estimated amount of users who will start using the app? If the application will not crash when 100 users will try to register at the same time? 

What will happen when the amount of data in the app will blow up, and the app will start to be very slow and unusable? Alternatively, the user will have to wait 5 minutes after application start on loading of everything needed?

Another example of a non-functional requirement is what should happen when your internet connection is lost? Should we show anything to the user? Alternatively, maybe there is a need that some features will also work in offline mode?

Lot, lot of questions, but if you do not spend some time on adhering them, then it will back to you at the end of development or… what is even worse when you will release production version of app, you will get the market and then suddenly you will see that users are very disgusted and stop using your app and you will lose much money, time and maybe your whole business will be killed even before it will grow.

Summary

We touched only few – but very important parts of this what should be defined before we start developing new application. Mark learned from it a lot. I’m sure that he will never make the same mistake.

In next part of series we will go with Mark through a solution domain – what we need to know to deliver a great application. 

Acute a problem is a must, and it’s a first important step. However, requirements don’t answer on next important question HOW we should implement the solution to answer on WHAT, WHEN questions.