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, the 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 forms were user stories – a popular way of describing what solution should answer.

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. 

The whole team involved in a project must have a feeling of the mission – the team is a part of something significant that can have a massive impact on desired users. Mission where everyone knows, understands, and feels that this impact is significant to users. 

In this case, it didn’t happen. For developers, the 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, the project manager validated that they are complete, but there was no phrase to see if these user stories will be enough to deliver a great product according to the vision and be still within budget. Pushing on a reasonable price was the most significant problem.

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

What is worse user stories were not defined well. They were written down as a list of tasks without putting attention to 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 the user story brings some value to the user. This is so simple, but in most of the projects, 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 and 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 answers the question – WHAT we should deliver? 

If a user story is well defined then also answer the question of WHY we should implement it at all. However, the user story never answers on question WHEN we know the hit user story is well implemented. Moreover, there 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’s 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 our forms 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 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 the 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, and how logic will work, but also you should think about such requirements as 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 the application starts loading 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?

A lot, lot of questions, but if you do not spend some time adhering to them, then it will be back to you at the end of development or… what is even worse when you will release the production version of the 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 a few – but very important parts of this that should be defined before we start developing new applications. Mark learned from it a lot. I’m sure that he will never make the same mistake.

In the next part of the 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 the first important step. However, requirements don’t answer on next important question HOW we should implement the solution to answer  WHAT WHEN questions.