How Agile Methodology can Help Your Startup Succeed! [7 Mins Read]

Many new start-up businesses don’t understand or know what software development methodology they need to adopt.

Different start-ups and entrepreneurs I talk to feel the software process is a direct outsourced arrangement. Basically you hire some someone, you give them your requirements, and they go away to build something in isolation. At the end of the engagement you find didn’t get what you wanted. Your involvement is limited during the whole development process, since you are involved at the very start and at the very end of the project. You are placing a lot of trust in the person or company performing the software development.

Avoid this!

What I just explained is an old way of planning and executing a software development project. In industry terms this is labelled as a waterfall approach and doesn’t meet the needs of modern start-up businesses.

Within my 14 years of software testing experience there is one key ingredient for a successful outcome. There is a methodology called agile that supports ongoing collaboration and also encourages continual user feedback from your target market. It is a fundamental change in thinking and requires your dedicated involvement to optimise a quality outcome. Software development is a journey.

When I refer to software development, I am referring to building software like an e-commerce or application that is available on a desktop, tablet and smartphone for example. One can apply an agile approach to building a static website, but sometimes that can be considered overkill. A static website might require a selection of a simple template with some customisation. The agile approach is best suited for a situation where you have an idea, but are not 100% clear on what to build. The idea will require refinement during the development process.

Please note the agile methodology can be modified to address the needs of your company or project. Being agile is also about being flexible.

Agile Planning for First-time Entrepreneurs

Agile planning uses epics and user stories (later in the text I’ll describe what exactly these are) as a way to write high-level requirements and acceptance criteria for projects. As the stakeholder (business owner) for the project, the goal is to write epics and user stories with just enough information so you can start building the project, but also leave enough room to shift gears or build more.

You can write epics and user stories on something as simple as an index card, or you can use online tools like Trello, Jira or Wrike.

What are epics and user stories?

Epics and user stories describe an audience, problem, and reason. What you’re building is a solution to the problem. What makes epics different than user stories is they are large stories too big to implement in a single iteration so they are broken into smaller, manageable chunks. Building epics helps make sure you define high level requirements before diving into the details of a project, so it’s recommended to start from there when you’re building out a project.

Write an Agile Epic

Epics are large user stories (ones that would take more than a few weeks to develop and test). If possible, split a large story or epic into smaller stories that can be completed within an iteration.

What to include

    • Epic title – A summary of the high-level requirements. This is often titled a topic. For example, if you’re an ecommerce business an epic title may be Purchases
    • Epic user story – A high-level epic description to the audience, problem, and reason that can then be broken down to smaller user stories
    • Acceptance criteria – A description of what is required in order to create a solution to the user story.
    • Included user stories – A list of the included user stories to keep track of the epic project.


Write a User Story

User stories describe your user and the reason why they need to use the service you’re building. Each project requires a user story when building a service so you’ll meet your user’s needs.

Informal user story format

(Audience) want (something).

For example, a user story can be,  “Customers want to purchase from a mobile app.”

Formal user story format

As a (role) I want (something) so that (benefit).

For example, a user story can be, “As a customer I want to purchase from your store from a mobile app so that I can shop on the go.”

What to include:

    1. User story – Describe the audience and what they want in an informal or formal format.
    2. Priority – Use a scale of one to ten or other prioritization approaches such as Low, Medium or High. You want to indicate the priority somehow in case you drop the deck of cards, or if you’re using online tools.
    3. Estimate size – Estimate the effort to implement a story with user story points. Story points are arbitrary numbers that indicate effort. Sometimes it’s great to start with hours worked.
    4. Non-functional requirements – Usage requirements are similar to use cases whereas technical requirements are similar to software functionality.


For example, a use case may be, “Customers want to purchase from a mobile device.” Whereas a technical requirement may be, “Customers items will be stored in the shopping cart.”

Utilising the Agile Methodology

Prior to starting the project, I am assuming you have researched your idea and target market. During this project example we will get select market users to provide feedback of your software throughout the project.

The agile methodology utilises the below basic steps:

    1. Evaluation/Prioritisation
    2. Requirements
    3. Design/Analysis
    4. Development
    5. Testing
    6. Deploy


 All 6 six steps combined create a concept called a sprint. Each sprint is assigned specific set of functions to be developed. E.g. Login and logout functions. Each function follows the 6 step process outlined above.

The evaluation/prioritisation phase allows you to identify the functionality that you want to develop. Basically you can define a list of functions/features or processes and then place them into sprints. In this example let’s assume we are building a stock trading application for a desktop, tablet and smartphone.

The function list can be allocated to sprints as outlined below:

    • Sprint 1Install Application
    • Login Function
    • Log out function
    • Modify customer details
    • Sprint 2Buy a trade (Local Market)
    • Sell a trade (Local Market)
    • Buy a trade (International Market)
    • Sell a trade (International Market)
    • Sprint 3Automated buy trade
    • Automated sell trade
    • Modify a trade
    • Sprint 4Cancel a trade
    • Deposit cash
    • Withdraw cash
    • Sprint 5Stock alert
    • Stock Search
    • Calculate capital gains
    • Portfolio Reporting


 In the below diagram I have identified 5 separate sprints that must each produce workable software.

Let’s assume each sprint lasts 2-3 weeks each and the aim is to identify requirements, design, development, and test. You can make available some functionality for market ready deployment in the first couple of sprints. Before you start, make sure to address how the trading application will handle the range of tablets, smartphones and other device from various manufacturers.

The great thing about this approach is at the end of each sprint you can release the software to select market users and they can provide feedback on what is successful and unsuccessful. This feedback can be added into the next sprints to refine your software. At the start of each sprint feel free to reprioritise functions that need to be addressed. This is what agile is designed to do.

For this process to be successful you are going to need a mature and experienced team. It requires solid collaboration between all members of the software team. You as the client need to make yourself available throughout each sprint to verify the team has built what you have envisioned. I can’t stress this enough. Make sure to book time in your diary to assess the output of each sprint and provide feedback to the next sprint.

Stock trading software would usually take more than 5 sprints in practice, but I have just kept it simple for this example. Depending on the software or project at hand, your project sprint durations could be 3 days, 1 week or 1 month. Work with your team to identify the best approach for your situation.

Today’s blog was specifically designed to educate you on an approach that sets you up for success. You need a process that is flexible. During the lifecycle of a software project you will change your mind on certain things and the agile process supports that approach.

Once again, I want you to succeed.

I would love to hear your opinions, questions or subjects you wish for me to cover.

Please post your feedback to me via the discussion boards below.

Share Button

Leave a Reply

Your email address will not be published. Required fields are marked *