When technological evolutions and the internet spread accelerate with astonishing speed, there's never been a better time to build a software startup — whether it's SaaS or custom software. It opens up tremendous opportunities for forward-thinking entrepreneurs to innovate and make a positive impact on the world.
While the landscape is open, the failure rate is still high. When software is the core product, one of the critical killers of startups is the lack of technical implementation. Literally, the ultimate success depends on how development teams understand requirements and how the startup founders navigate the development process toward market acceptance. Consequently, startup founders need to equip themselves with an effective method to translate their business ideas into an actionable development plan. Whether they work with their in-house product team or collaborate with an offshore development team, it all comes down to a critical skill - writing the software product specifications.
In this article, we talk about how to write an effective product specification document in an Agile way that helps startup founders either design a robust MVP implementation plan for their in-house team or initiate a strong collaboration with an offshore software house. There are considerable benefits in short-term and long-term angles coming up from properly writing product specification:
- Design the product requirements, which enables the findings of product-market fit.
- Provide a clear and well-articulated input for the development team to action.
- Stimulate the discussion that makes the most of collective expertise.
Manage the development tasks effectively and have quicker deployment. - Have a more accurate estimation of time and cost in record time.
Why should startups write a product specification in an Agile way
The concept behind the product specification is to provide the product team the whole picture of what features should be included, how they should be built, with complete clarity and transparency. Very often, we see product specification documents come along with waterfall projects.
However, in the waterfall approach, it often takes the first several weeks or months to analyze the business model and build up comprehensive specification documents of the whole product from the very beginning of the project. The final result is a collection of detailed specifications, diagrams, and steps by steps on how to build the functional software. Meanwhile, the whole project could take months or years before it's delivered. Odds are those documents could become less valuable in times of need.
In the startup world, the ability to quickly ship products, test the market, and learn from market indications is far most important. That's the reason why the waterfall approach becomes obsolete in this case. On the other hand, the Agile iterative process allows the startup to break down the long cycle of development into small iterations (sprints) and just define the project's broad scope upfront. Agile startups have higher chances of getting feedback from early deliveries, which gives them the confidence to realize what is the most important to their business and refine them as needed. As a result, this is the main point that leads to the compatibility between Agile development and building startup products, especially in the MVP phase.
When consulting for different startups over the past few years, we realize that writing product specifications in the Agile way is the best approach to help our startup clients break down their product requirements in the most systematic yet intuitive way, despite the complexity of the project. It bridges the gap between them and the development team even when founders don't have a technical background. A well-versed product specification gives founders a clear view of how the end-user will use their product and how the development team will develop each feature.
How to write the "Agile" software product specification
Two essential components that make the "Agile" product specification clear and impactful are user stories and acceptance criteria. In this section, we're going to explore how to write them properly.
User stories
In order to find out the best fit between your software product and market demands, your requirements should be written in a type of user story.
From a startup founder's perspective, a user story is a general explanation of some software functionalities with the end user's demand at the center of the conversation. The purpose behind this is to articulate how a software feature provides value to the customer.
From the development perspective, user stories describe the why and the what behind the development team's day-to-day work. After reading the user stories, they know what they are building, why they are building it, and its values. In a sense, user stories' presence creates the motivations and purposes for the whole team to keep shipping and run a smooth development process.
The user story is written in non-technical language with the following format:
|
As a [type of user], I want to [perform some actions] so that I can achieve [some goals/values/results]
|
Example: As a worker, I want to upload screenshots for verifying my gig economy experience.
User stories help break down the whole system into different small chunks of information that cover all necessary system inputs like user types, user roles in the system, their desired activities, and what they receive after completing the user stories. With a backlog of user stories, your requirements are described clearly and structured so that the technical team could understand and set a development plan right away.
Acceptance criteria
To complete the picture, we use acceptance criteria to adequately address the founder's expectations for their product. Acceptance criteria specify all conditions, scenarios, or business rules that a user story is fulfilled. It's the primary tool for us to clear out the ambiguity of requirements and miscommunication between startup founder/PO and developers.
There are several types of writing acceptance criteria, but the most common ones are scenario-oriented and rules-oriented.
Scenario-oriented format
Scenario-based acceptance criteria come with the following format:
|
[Scenario name] Given [the beginning start of the scenario]
|
Example:
Given the user successfully created an account.
And the user updated their basic details.
When the user clicks on “verify experience” on the “profile task view” UI.
Then display a list view of the selected gig economy platforms.
And allow the user to upload one screenshot per platform.
This format initially came out from behavior-driven development (BDD). It sets an apparent boundary of the founder's expectations. It also provides a clear structure for testers/QA to define the beginning and end of a particular test case.
Rule-oriented format
It is a set of rules, which describe system behaviors and enable developers to create scenarios. In that case, criteria are given as a list. There are several cases that rule-based format that comes into play rather than scenario-oriented:
- Scenario-oriented can not cover the design and user experience constraints of features and any other critical details.
- The project does not need precise details of test scenarios.
The format of rule-based includes the following form:
|
|
Example:
- Verify that when the user clicks on a gig economy platform button (e.g. DoorDash), then open native photo upload functionality.
- Verify that the “Done” button disabled until the user uploads one screenshot for each gig economy platform.
- Verify that when the user clicks on the “Done” button after uploading all required screenshots, then display the “My profile” UI.
Best practices to write better user stories and acceptance criteria
The above guidance has laid you the foundation for translating your business requirement into a well-versed product specification document in an Agile way. But in reality, you might face some common mistakes and can not gain the ultimate benefits from creating this type of documentation. Several following practices might be helpful along the way.
User story
- To not fall right into the chaos of a dozen stories, they should be organized in epics and initiatives. Multiple user stories comprise an epic, and various epics form an initiative. And stories should be prioritized in different sprints and iterative releases.
- The persona in user stories should not be stopped at a job title but the actual persona of a user, who they are, how they think and feel. It provides the context for what underlying jobs or desires the users will make on the software. Without it, you could develop perfect software that offers no value to the users.
The following process could help you to build up your end users' understanding.
- The user stories should be detailed that enable actions for the development team. If they still need another layer of narrative, these user stories might still be broad. And last but not least, it should be testable.
Acceptance criteria
- The acceptance criteria should be documented before the actual development phase and reach a consensus between both parties. It also helps to set the foundation for developers and testers to plan their technical processes.
- The acceptance criteria should be measurable. It should not be too broad that makes the user stories vague. But it should not be narrow that can not cover multiple user behaviors. It should also be achievable that does not make the development team stuck with dozens of small tasks.
- It also allows testers to verify that all requirements were met. Otherwise, the developers can not understand when the user story is completed.
In a nutshell, the art of creating this kind of document lies in how we define the detailed limit for our writing, and it's best to be based on the collective knowledge of the startup founder and development team.
Final thoughts,
Here, it's tempting that all the above processes scare you off. However, we believe the time you invest in describing and specifying all your requirements in user stories and criteria will eventually pay off. It creates a win-win situation for both the development team and you as a startup founder. Not only does the team know what they have to do, but you can keep your focus on designing a product that fits with the market demand. With the support of iterative Agile, it allows you flexibly build and test to make sure the final product reaches market acceptance, which eventually securely protects your bottom line.
Either the startup founder or a development team writes the product specification. However, at Enlab, we encourage strong collaboration from both sides to make the most collective experience. Based on that, we could provide the most reasonable estimate of time and cost.
Please tune in to discover how we estimate the cost of a custom software solution for our client in the next post.
References
- Alexander Cowan, Your best Agile user story, www.alexandercowan.com
- Agile Alliance, Given-when-then definition, www.agilealliance.org
- Max Rehkopf, User Stories with Examples and Template, www.atlassian.com
