Surely the memories of struggling to match each color to their relative faces streaks across your mind… Maybe a few seconds, minutes, or hours pass; the challenge persists until you win the game!
Dominating the modern era of Business Analysis in 2021, the demand for frictionless User Experience (UX) has generated avid attention in the recent past. With the surge of online engagements over in-person interactions, the need for businesses to maintain a competitive edge in UX is of paramount importance. A business analyst’s role in bridging the gap by understanding customer/ stakeholder needs to match product expectations, in reality, has become an arduous Rubik’s Cube challenge to solve.
Overall, the focus of Business Analysis has shifted towards pursuing the needs and experience of the end-user where business objectives are now re-aligned to be more customer-centric. Failing to complement new business trends with rapidly changing demands could have an adverse impact on product usability, customer retention, and organizational profits.
Fear no more! Using a few UI/UX tactics in ‘Design Thinking’ up your sleeve will swiftly unlock your potential to tackle even the toughest of business problems!
Analyzing end-user experiences when defining requirements during Design Thinking phases are crucial.
This can be fulfilled by incorporating 8 simple UI/UX techniques and practices into your daily work routine. The integration of these concepts into interaction points during development will immensely enrich the vital components of your product’s user journey.
STEP 1 – EMPATHIZE
1. Use Visual Representations for Effective Communication
“Put yourself in my shoes” is a statement commonly used to empathize with one’s perspective, opinion, or point of view. Effective communication with customers/stakeholders plays a crucial role when immersing yourself in their context to identify basic needs. A plain sketch or a rough diagram to support you with this could surprisingly go a long way to avoid misconceptions and reduce product reworks.
A well-known example to prove this would be the utilization of a ‘Prioritization Matrix’ to communicate the priority of features based on their urgency and importance. This technique will assist you to acknowledge the clear-cut expectations of your stakeholders and contribute to streamlining the requirement process to be more objective and evidence-based.
2. Balance Attention between Business Objectives and UI Expectations
All five fingers of the hand do not look the same. Similarly, users and their way of thinking varies from one person to another. Practice driving requirement gathering discussions and the requirement elicitation processes to not only focus on the business objective but to simultaneously note down any existing/potential User Interface (UI) related concerns. The balanced attention that you will eventually acquire guides you to look at problems from a diversified viewpoint.
3. Analyze Similar Products in the Market
Conduct a competitor analysis on the UI of similar products in the market with fresh eyes on the fundamental aspects of product attributes such as usability, navigation, content, and design at a business level. Inspection of the competitive market including customer reviews, ratings, and comments will open more opportunities for further improvement and identify ways in differentiating your product amongst competitors.
STEP 2 – DESIGN
4. Obtain Feedback and Brainstorm
Undergoing several iterations of gathering feedback may sound tiring… but worth the effort! Ensure that stakeholders are kept informed of product-related decisions throughout the product development process. Request a quick call to review the design and verify that you’re on the right track with what is expected. Any requested modifications could easily be incorporated before actual implementation during this phase.
Once the stakeholders are satisfied, a quick solution walkthrough in no more than 30 minutes to your internal team would help discover any misconceived notions from the ‘Empathize’ phase. Furthermore, brainstorming will aid you with validating your solution of its practical feasibility before the project moves forward. Though time-consuming, this will certainly reap the benefits of avoiding expensive re-works later in the process!
5. Write Requirements to match Basic UI/UX Standards
UX on usability, navigation, content, and design defines the levels of product-user interaction. Keep a lookout when writing requirements to match the product design where the look-and-feel should be consistent throughout the application. To ensure your expectations meet the product reality, business analysts should provide detailed guidance on some of the following essential elements when writing requirements.
Example: Upon clicking on the ‘Help’ hyperlink, the user will be navigated to the ‘Help & Support Services’ page.
Additionally, it is important to address the actions that will be triggered upon the user clicking on Action Buttons, Tabs, Page Scrolls, Icons, Dropdowns, etc.
STEP 3 – IDEATE AND PROTOTYPE
6. Utilize Modern Prototyping Techniques
Like the importance of a trailer for a movie, prototypes play a critical role in the product development process. Integrating prototyping techniques such as wireframes and storyboards will provide an overview of the entire product with emphasis on core components to the stakeholders and the organization.
Wireframes – these tools act as a visual guide to portray a screen blueprint or a page schematic to illustrate the business functions of a feature.
Storyboarding – a technique that allows users to navigate through a series of wireframes/images to represent the sequential flow of how a process works.
Example: InVision, Boords, Frame Forge, Panel Forge Adoption of prototyping as early as possible to obtain stakeholder/customer feedback will assure that the requirements are in line with the expectations of your users! Moreover, it fosters your creativity to play around with toolkits like Microsoft Word and Excel to come up with matrices that clearly visualize requirement needs.
This is a form of the ‘Mini-Skirt’ approach which will help you to cover the requirement essentials with as minimum textual content as possible to avoid readers missing out on details, save more time and ensure that your information is communicated in the way it is intended to!
7. Brainstorm Again!
Discuss with your team, stakeholders, and users (if possible) by walking them through the prototypes. This will help identify any requirement gaps, areas to be improved, and pinpoint any trivial details which can be omitted! Evaluate and modify the prototypes based on the provided feedback to further refine the final output to match your customer/stakeholder needs.
STEP 4 – TESTING
8. Observe your Users to Validate the Final Solution
Apply the ‘Contextual Inquiry’ method from the ‘Open Innovation’ concept to validate your product expectations. Allow users from different environments to use the application and observe their behavioral patterns to understand any UX-related concerns which might have been overlooked in the previous phases. Question users on difficulties they faced and any suggestions which could enhance their experience with your product. This way, you will gain valuable insights by learning through users to recognize where your product stands against its expectation, aiding you to interpret the gap between the two.
Acknowledgment of these 8 core UI/UX concepts in Design Thinking will doubtlessly act as a vital catalyst to supplement your customers, project stakeholders, and organization by saving more time and extra dollars spent on rework.I believe in the saying; “Experience Speaks Louder than Words” and it is the right time for you to take up your Rubik’s Cube challenge and try solving the puzzle once more… BUT this time with a few good tools to guide you along the way. Good luck!
Associate Business Analyst
Achieving Product-Customer Fit Using a Value Proposition Canvas
The end goal of any entrepreneur is to generate profit through the products they are working on. To reach this goal these individuals simply need to ensure that the values they offer to the end customers through these products are needed and worth the customers spending their hard earned money on.
However, Simon.Kucher & Partners found out in 2014 that 72% of new products and innovations fail to deliver on customer expectations. In other words, 7 out of 10 new products and innovations introduced to the market does not matter to end customers. To turn this around, the entrepreneur needs to offer a product that fits the end customer’s needs.
A rational customer would spend their money on a product that would fulfil an existing need of theirs. Depending on the customer and the economic background, customers tend to spend their money to fulfil a set of needs based on order of priority. These needs can be categorized into 3 types: functional needs, social needs and emotional needs. A typical customer would not analyse their needs or types of needs and think of new products they would like to have. Instead, they can be introduced to new products that would solve a current need or pain point of theirs through a product advertisement or a recommendation. Firstly, these needs or pain points need to be understood and verified by the entrepreneur.
A famous quote by Henry Ford says “If I had asked people what they wanted, they would have said faster horses.” What is to be learnt from this statement is that the customer will never tell you what the best product or solution is. Instead, they will tell you what their problem is. It is upto the entrepreneur to come up with the product in this case, after identifying that the customer’s need is to travel faster.
What triggers a customer to realize a need that a product is solving for and make them want to purchase it?
It is the Value Proposition of the product.
The value proposition is a descriptive statement of the value which will be offered to a customer through a particular product that compels the customer to make the purchase.
It is significant for entrepreneurs to identify a unique value proposition for a product to succeed and continue to make revenue in the marketplace.
To make the lives of those who wish to arrive at unique value propositions easier, Swiss business theorist Dr. Alexander Osterwalder has invented a tool called The Value Proposition Canvas. This tool simplifies the complexity of visualizing, designing and testing how value can be created for customers. It helps visualize the profile of the target customer in terms of their needs and the value that needs to be offered to them to arrive at the product-market fit in a collaborative manner. It also helps entrepreneurs map, think through and discuss the value proposition in relation to the targeted customer. Most importantly, the tool makes it easier for us to put ourselves in the shoes of the customer when we design the product and avoid making products that the end customers don’t want.
It is ideal that a value proposition canvas is used at the beginning of designing a product itself. However, if a product is already developed, using the canvas will help identify where the already designed product would fit in the market or what improvements can be made so that customers actually want the product.
The Value Proposition Canvas
The value proposition canvas consists of two main components, the customer profile and the value map.
The jobs refer to the jobs that the customer is trying to get done through a new product, or their needs in other words. As mentioned above, these needs could be functional, emotional or social.
If you are the entrepreneur and needs to understand the customer jobs better, ask yourself the questions below,
What functional jobs is my customer trying to get done? (e.g. perform or complete a specific task, solve a specific problem, …)
What social jobs is my customer trying to get done? (e.g. trying to look good, gain power or status, …)
What emotional jobs is my customer trying to get done? (e.g. esthetics, feel good, security, …)
What basic needs is my customer trying to satisfy? (e.g. communication, convenience, …)
Once the jobs are identified, they need to be verified and prioritized or ranked through conversations with actual customers. The importance of considering all three types of needs is that it helps understand everything that matters to the customer when it comes to their overall need. The value proposition statement can address the need that matters most to the customer and get the customer’s attention easily.
The pains can simply be described as the reasons why a customer is looking for a new product. These are negative emotions, undesired costs or situations, and risks that the customer experiences or could experience before, during, and after getting the job done. These are mostly attributable to the current existing solutions.
A good understanding about existing solutions can be obtained by carrying out a product landscaping.
Pains could be better understood by asking yourself the questions below,
What does my customer find too costly? (e.g. takes a lot of time, costs too much money, requires substantial efforts, …)
What makes my customer feel bad? (e.g. frustrations, annoyances, things that give them a headache, …)
How are current solutions underperforming for my customer? (e.g. lack of features, performance, malfunctioning, …)
What are the main difficulties and challenges my customer encounters? (e.g. understanding how things work, difficulties getting things done, resistance, …)
What negative social consequences does my customer encounter or fear? (e.g. loss of image, power, trust, or status, …)
What risks does my customer fear? (e.g. financial, social, technical risks, or what could go awfully wrong, …)
What’s keeping my customer awake at night? (e.g. big issues, concerns, worries, …)
What common mistakes does my customer make? (e.g. usage mistakes, …)
What barriers are keeping your customer from adopting solutions? (e.g. upfront investment costs, learning curve, resistance to change, …)
Similarly to the jobs, it is important to prioritize the pains according to the intensity that is relevant to the targeted customer through conversations with real customers.
Gains are how customers measure the success of a job done well. Gains in other words are the positive outcomes, benefits and aspirations customers need to achieve that supersede what is offered through existing products. These will increase the likelihood of customers adopting a new value proposition.
Gains could be better understood by asking yourself the questions below,
Which savings would make my customer happy? (e.g. in terms of time, money and effort, …)
What outcomes does my customer expect and what would go beyond his/her expectations? (e.g. quality level, more of something, less of something, …)
How do current solutions delight my customer? (e.g. specific features, performance, quality, …)
What would make my customer’s job or life easier? (e.g. flatter learning curve, more services, lower cost of ownership, …)
What positive social consequences does my customer desire? (e.g. makes them look good, increase in power, status, …)
What are my customers looking for? (e.g. good design, guarantees, specific or more features, …)
What do customers dream about? (e.g. big achievements, big reliefs, …)
How does my customer measure success and failure? (e.g. performance, cost, time taken…)
What would increase the likelihood of adopting a solution? (e.g. lower cost, less investments, lower risk, better quality, performance, design, …)
At times it may seem that the pains and the gains are differentiated by a blur line when you actually start working on a value proposition canvas. The key difference between the two is that pains refer to negative outcomes the customer is trying to eliminate and the gains refer to what the customer will be delighted with.
Similarly to the jobs and pains, gains should be prioritized according to how significant it is to the targeted customer through conversations with real customers.
In sum, the customer profile can be used to visualize, test and understand the customer we are creating value for. Upon understanding each section of the customer profile, the entrepreneur can start filling out the value map addressing each point that was listed.
This is the list of products and services the value proposition builds on. This could be a list of products the entrepreneur (or you) has in mind that will fulfil the customer jobs, pains and gains.
Which products and services I offer will help my customer get either a functional, social, or emotional job done, or help him/her satisfy basic needs?
Products and services may either be tangible such as manufactured goods, face-to-face customer service, digital or virtual such as downloads, online recommendations, intangible such as copyrights, quality assurance, or financial such as investment funds, an insurance policy or a financing service.
Ranking each of these products and services based on importance to the customer will help you to arrive at the best fitting solution.
The pain relievers are descriptions on how each of the customer pains are addressed through the proposed new product to eliminate or minimize the pains. This needs to fit the list of identified pain points of the customer. These will also describe how underperforming products can be fixed.
To arrive at a refined set of pain relievers ask yourself,
How will my product eliminate or reduce negative emotions, undesired costs and situations or risks my customer experiences or could experience before, during, and after getting the job done?
How will my product produce savings? (e.g. in terms of time, money, or efforts, …)
How will my product make my customers feel better? (e.g. kills frustrations, annoyances, things that give them a headache, …)
How will my product fix underperforming solutions? (e.g. new features, better performance, better quality, …)
How will my product put an end to difficulties and challenges my customers encounter? (e.g. make things easier, helping them get done, eliminate resistance, …)
How will my product wipe out negative social consequences my customers encounter or fear? (e.g. loss of image , power, trust, or status, …)
How will my product eliminate risks my customers fear? (e.g. financial, social, technical risks, or what could go awfully wrong, …)
How will my product help my customers better sleep at night? (e.g. by helping with big issues, diminishing concerns, or eliminating worries, …)
How will my product limit or eradicate common mistakes customers make? (e.g. usage mistakes, …)
How will my product help my customers get rid of barriers that are keeping them from adopting solutions? (e.g. lower or no upfront investment costs, flatter learning curve, less resistance to change, …)
Similar to the rest, pain relievers also need to be ranked according to the intensity that is relevant to the customer.
Gain creators are descriptions on how the product will produce, increase or maximise the customers’ expectations or desires. Gain creators also explain how the new product will outperform what the customers are currently using. These need to address the gains mentioned in the customer profile.
To arrive at the set of gain creators, ask yourself,
How will my product create savings that make my customer happy? (e.g. in terms of time, money and effort, …)
How will my product produce outcomes my customer expects or that go beyond their expectations? (e.g. better quality level, more of something, less of something, …)
How will my product copy or outperform current solutions that delight my customer? (e.g. regarding specific features, performance, quality, …)
How will my product make my customer’s job or life easier? (e.g. flatter learning curve, usability, accessibility, more services, lower cost of ownership, …)
How will my product create positive social consequences that my customer desires? (e.g. makes them look good, produces an increase in power, status, …)
How will my product do something customers are looking for? (e.g. good design, guarantees, specific or more features, …)
How will my product fulfill something customers are dreaming about? (e.g. help big achievements, produce big reliefs, …)
How will my product produce positive outcomes matching my customers success and failure criteria? (e.g. better performance, lower cost, …)
How will my product help make adoption easier? (e.g. lower cost, less investments, lower risk, better quality, performance, design, …)
Gain creators too need to be ranked according to how substantial it is to the customer. It is important to consider how often each gain would occur.
The product-customer fit can be achieved by making a clear connection between what matters to customers and how the products and services listed in the value map eases each pain and creates the gains. The great value proposition targets the customer jobs, pains and gains that are most important for the customer. The canvas will help highlight the key points that need to be focused in order to arrive at a good value proposition and at the same time make sure that there are no more solutions than problems.
Below is a simple and basic real life example of how the value proposition canvas was used to identify a fitting use case for a product that was already designed.
The product is a UVC germicidal box and the target customer is the head of the house keeping department of a healthcare facility that is not a current user of existing UVC solutions. (UVC refers to ultraviolet light with wavelengths between 200 – 280 nanometers and can be used to destroy harmful microbes.)
It is important to select the customer who makes the buying decision as well as to consider the customer who actually uses the product. Both types of customers were profiled to arrive at this value proposition (open for refinement). Indicated is one example.
This was a collaborative effort between the Business Analyst and the Product Engineer. The customer profile was filled by the Business Analyst based on secondary research and requirements elicitation to cover the customer jobs, pains and gains of health care professionals/staff members related to sterilizing needs of delicate utensils. The value map was filled by the product engineer to address each identified customer job, pain and gain.
The improvement done to the already designed UVC germicidal box was to add a tray which standardizes the way delicate utensils are placed inside the box ensuring proper exposure to UVC and to provide instructions on how items need to be placed. Because once the pains were analysed, it was realized that there will be a challenge in sterilizing irregular shaped items as the UVC may not reach all of its surfaces.
The value proposition is “A trusted and consistent 50 second sterilization mechanism for delicate medical utensils and electronic items” The specific time 50 seconds mentioned in the value proposition is how the customer measures the success of the solution. Everything that is listed in this canvas including the value proposition needs to be validated through interaction with actual customers.
The reason for selecting a non-user of existing UVC solutions as the target customer was that there were already similar existing solutions out there in the market at the time this exercise was done. The importance of using the value proposition canvas prior to designing a product is, it allows us sufficient time to carry out a product landscaping which helps us identify existing solutions to the identified customer jobs, pains and gains and help us create a differentiated and unique product.
Indicated in the table below are few questions that was asked to arrive at the points listed in the above value proposition canvas
What functional jobs is the customer trying to get done?
Have an efficient and productive sterilization mechanism in place for the fragile utensils and electrical equipment such as stethoscopes, pressure cuffs, mobile phone, and digital thermometers.
What emotional jobs is the customer trying to get done?
Have a trusted sterilization mechanism in place.
What makes the customer feel bad?
Concerned about harmful side effects caused to staff and patients by chemical residue
What does the customer find too costly?
Higher time and effort of cleaning staff needed in sterilizing fragile utensils one at a time
What would increase the likelihood of adopting the solution?
Quick and efficient process of sanitizing delicate equipment
What is the customer looking for?
Efficient sterilization of delicate electronic equipment of regular and irregular shape which can’t be sterilized in high heat or using chemicals
How does my product make the customer feel better?
Uses UVC irradiation for surface sanitization enabling sterilization of electronic equipment and eliminating the need for chemical use
How does my solution produce outcomes the customer expects or that go beyond their expectations?
Emits a dosage of UVC rays capable of removing disease causing microbes in 50 seconds
Described below is an example where it was recommended to disregard a solution as existing solutions superseded in terms of solving the target customer pains. This is an example where the value proposition canvas can be used to make sure we “Fail Fast” if we are not creating the correct product-customer fit. It is important to identify the unfit early before we pour our blood, sweat and tears into designing a product solution.
The purpose of the product was to sterilize an aircraft. The proposed design was a movable platform with UV tubes mounted on retractable wings to reach from one end to the other of the aircraft cabin. The estimated sterilizing time per one row of seats was three (3) minutes. However, it was realised that the product would not meet the main requirement of sterilizing the aircraft in the short time span which lies in between domestic flights. It was important to sterilize the aircraft in between flights to ensure that the germs which come from one set of passengers do not get passed to the next set of passengers. A solution that eliminates the pain point of having to sterilize the aircraft in between flights itself was eliminated by an existing solution which was a chemical spray which remains on the interior surface effective for 10 days in absorbing and inactivating the germs. Hence, there was no requirement of creating a value proposition for the product. It is an example why it is important to carry out a product landscaping after identifying customer jobs, pains and gains.
Indicated in the table below are few questions that was asked to arrive at the points listed in the above value proposition canvas
What functional jobs is the customer trying to get done?
Ensure cleanliness and sterilization of the cabin spaces, galley and washrooms is achieved within the limited time available between flights
What are the main difficulties or challenges the customer encounters?
Impossible to sanitize all surfaces touched by passengers within the limited time available between flights
What is the customer looking for?
Quick and effective method to free the aircraft interior from disease causing microbes within the timeframe available between flights. (It was found that the solution already exists in the market)
As a Business Analyst or Entrepreneur if you are required to design a winning product with a unique value proposition, please make use of the value proposition canvas which helps you visualize, design and test your value proposition. Please try this out and you will understand the benefit it creates in terms of stimulating your creative thinking.
In my opinion, “Stimulate your creative thinking to achieve product-customer fit” is the value proposition that is offered to you through the value proposition canvas.
Note: According to the owner of the value proposition canvas Alexander Osterwalder, software companies are required to license the value proposition canvas poster from Strategyzer prior to using it.
User Stories! they do sound simple when we hear them for the first time. Surprisingly, it is not the case when taking up the actual job. Writing user stories in such a way to minimize the ambiguity, inter-dependency etc. while maximizing the value to the stakeholders is not always simple.
I have encountered the same problem and came across a useful mnemonic, which gave me the right solution I have been questing for; the INVEST approach for user story writing.
Why do you invest in anything?
We invest in a wide range of things. Some invest in stocks, treasury bills or real estate. A Business Analyst canINVEST in writing good user stories, aiming for the best understanding of his/her stakeholders!
In agile software development, the textual requirements usually come in the form of user stories. The common format of a user story is,
As a <user>I want <goal>so that <reason>
User stories are referred to by various stakeholders like customers, Project Managers, Developers, Quality Engineers etc.. Therefore, writing good stories brings an indispensable value, to maintain the mutual agreement between stakeholders on the requirements.
One such approach to get user stories ‘right’, is INVEST!
Why did Bill Wake come up with INVEST?
In 2003, Bill Wake in his book Extreme Programming Explored, coined the term ‘INVEST’ for the first time. He described a set of 5 aspects that should be taken into consideration when writing a good user story.
The birth of a good user story began there!
Let us decode INVEST!
INVEST is an acronym that describes 5 fold aspects of a good user story.
Independent: When delivering requirements, two user stories should function as independently as possible. There are three types of dependencies that can exist between user stories as;
User stories should not deliver overlapping requirements. Such stories will create confusion on whether requirements were covered in at least one of them.
User stories should be able to work in any order- not “this feature should be implemented after that particular feature” way. Sticking to particular order will complicate the development unnecessarily.
Though it is helpful to arrange user stories hierarchically for better understanding, it might not always list the most valuable stories on the top.
Negotiable: A user story should grasp the cream of the requirement, not essentially the details. The negotiation between customer and the team will derive the actual result. The goal of the user story should be to reveal the true need of the customer.
Valuable: A user story should be valuable to the customer/intended user of the story. User stories should be prioritized in such a way to deliver value to the end user. <So that> part in user story format usually unveils the reason for doing this. Any user story that does not carry a perceptible value to its user should not be done.
Estimable: A user story can be prioritised after it is estimated. This estimation can be a rough value. In case the story cannot be estimated, breaking into a few other user stories will give more sharpness and clarity to the stories.
Small: The user story should be a small chunk of work rather than a big chunk of work which is not scalable. They can be completed within a given time period(sprint). This time period varies depending on the methodology the team follows. E.g.: for agile, it is usually 2 weeks.
Testable: A good user story should be testable to the team as well as end users. It ensures the shared understanding between the stakeholders. When writing the user story, the acceptance criteria unveils the testable points in the story.
An Example is worth many hours of reading!
Let us see the following requirement.
“The ABC bank maintains a website for its customers. During the pandemic, the bank encourages its customers to use e-banking services offered via the website without visiting the bank premises in person. As a security measure, the bank expects to introduce OTP facilities for its customers.”
“AS AN ABC bank customer I WANT to use one-time access code to access e-banking services offered from bank website SO THAT I can securely complete transactions from my account online”
Does this user story INVEST-able?
It can definitely be improved!
Some of the questions that come to mind after reading above user story are,
Do all the customers of this bank get web access?
If not, which type of customers(Existing/Inactive etc.) has the access?
What should be the behavior of the system if the existing customer who has intentionally opted out from the above facility logs in?
What should be the behavior of the system if the existing customer has opted in for the above facility and logs in?
Assuming that the existing account holders of the bank who have opted in to OTP facility will be using this feature, let’s recreate our user story.
“AS AN existing ABC bank account holder with OTP facility, I WANT to use one-time access code to access e-banking services offered from bank website, SO THAT I can securely complete transactions from my account online”
Now the above user story is Independent.
It is also Negotiable because, if the bank decides to extend this OTP facility to its mobile application also, then we can further break down the user story as below.
“AS AN existing ABC bank account holder with OTP facility I WANT to use one-time access code to access e-banking services offered from mobile application SO THAT I can securely complete transactions from my account online”
The new user story brings Value to its account holders by allowing them to securely complete the monetary transactions online. From the perspective of the bank, it will ensure the authenticity of the transactions occurred and limit online frauds.
The user story is now Estimable as we have broken it down into independent, negotiable, valuable and small chunks.
It is also Small enough to be developed within a sprint.
Finally, the user story is Testable with all above qualities acquired.
Towards excellent user stories!
As depicted in the above example, the INVEST approach to user story writing delivers a wide set of advantages to not only the Business Analyst but also to the entire pool of stake stakeholders.
In practical terms, INVEST approach,
minimizes occurence of dependencies between user stories(most valuable stories first!),
identifies the right value and builds around it(we don’t build useless features!),
not going for big chunks of work but estimable and small work chunks.
helps maintain the shared understanding among stakeholders(Customer, Project Manager, DEV team, QA team etc.).
As someone who is already using this approach, I have been able to procure many of the above benefits.
Therefore, it’s high time that you INVEST on user stories you write!
The scenic, historic city of Russia, would probably come into your mind when you hear the word ‘Moscow’. Would you be surprised to learn that Moscow is not just the capital of Russia but also a very important prioritization technique that is used to decide what should be built and shipped in project deliveries all around the world?
How it all started
The MoSCoW technique/method also known as MoSCoW analysis/prioritization was initiated by Dai Clegg, a software development expert during his tenure at Oracle. Originally, the MoSCoW method was designed for time-boxed projects as a prioritization framework.
You must be wondering, ‘what’s a time-boxed project?’. These are the projects which have a previously agreed period of time during which a person or a team works steadily towards completion of a goal/s.
Typically, when considering a fixed timeline, it’s important to identify the relative importance of work that is required to be completed whilst making progress and keeping deadlines in mind. One of the most important decisions that a team has to make in a project is to decide ‘What’, ‘When’ and ‘Why’. Getting this right is paramount to being effective in impactful delivery. This is where prioritization plays a major role. Prioritization can be used for requirements, user stories, tasks, tests and acceptance criterias.
However, currently the usage of this MoSCoW method has broadened widely and has been adapted by many users across multiple domains.
The MoSCoW method in simple terms
Let’s take a look at what the MoSCoW method is and what we can do with it.
MoSCoW in simple terms, is a prioritization technique that helps in identifying and managing priorities. It is specifically used as an aid in projects when prioritizing requirements.
Here’s what MoSCoW stands for –
The use of MoSCoW in requirement prioritization
Among the numerous things that can be prioritized using the MoSCoW technique, the focus of this article is on how it can be leveraged to support requirement prioritization and the role that each of these rules play in when used in the requirement prioritization process.
Must Have – Like the word suggests, the requirements that fall under this category consists of the Minimum Usable Subset (MUST) of requirements that the project is assured to deliver which are typically mandatory and non-negotiable for the product, project or release.
For example, when considering a release for a banking application, some must-have requirements might include security functionalities in order to maintain compliance.
The requirements that belong to this category can be easily identified by asking yourself the question ‘what happens if this requirement is not met?’. If the answer is ‘the project/release would be useless without this in place even if we deliver on time’ then it can be considered as a ‘Must Have’ requirement.
Should have – These requirements are merely a step below the above mentioned ‘Must have’ requirements. Though meeting these requirements can be considered to be important to the product, project or release they are not vital to be met. Even if these requirements are left out, the product/project will still be able to function. However, if these are included, a significant value will be added.
The main difference between ‘Should have’ and ‘Must have’ requirements are that the ones that belong to the ‘Should have’ category can be pushed back to be addressed in a future release without impacting the current one.
Some examples of these include minor bug fixes and performance improvements.
For example, a ‘Should have’ requirement when considering a transportation application such as Pickme or Uber would be to have the option to rate and provide feedback on the driver and the overall experience.
Could have – The requirements that fall under the ‘Could have’ category are also referred to as ‘nice-to-haves’ and considered as ‘desirable but less important’. These are not necessary to the core functionality of the product/project when compared with the ‘should have’ requirements and these can be considered to be taken up only if there is extra time and budget allocated. Typically, When a problem occurs in the project and the deadline is at risk, the requirements that are placed in the “could-have” category are often the first to be deprioritized since they have much smaller impact on the outcome if they are left out.
For example, when considering an online clothing store, a ‘Could have’ requirement would be to provide information regarding the specifics of the material. Without this the user will still be able to find the clothing item they are looking for but having this will provide more options to the user to make their choice.
Will not have – These are requirements which the project team has agreed to not be delivered within the considered timeframe. Identifying and categorizing requirements into the ‘Will not have’ category is one way to help prevent scope creep. Some of the requirements in the “will-not-have” group will get prioritized in the future, while others are not likely to happen in the foreseeable future. A subcategory within this can be created in order to identify these requirements.
For example, integrating a virtual assistant or a chat bot in the website for an online store could be considered as a ‘Will not have’ requirement.
Which category each requirement belongs to depends greatly on the domain, stage of the product, the vision of the product and many other factors.
Tips and recommendations
Now that we have covered the MoSCoW rules, before the actual requirement prioritization process can take place there are a few things that need to happen.
Firstly, the product team and other relevant stakeholders need to discuss with one another and get aligned on project objectives and prioritization factors.
Then, all participants must agree on which initiatives to prioritize. This step is extremely important as it will prevent disputes and disagreements in prioritization before they take place which might lead to hindering the project progress.
Finally, it is also important to reach a consensus on the percentage of resources that will be allocated to each category which will make it easier when conducting the requirement prioritization and deciding on what requirements can be considered for each category.
Is the MoSCoW method for everyone?
You might be wondering, ‘is the MoSCoW method suitable for any kind of project?’. The answer is not all the time. Even though this is a simple and quite effective method of prioritization, it might not always work well with projects that have a very complicated backlog with numerous time sensitive releases.
However, if you are on the lookout for a well recognized and widely approved technique for prioritizing requirements, using the MoSCoW method is a great place to start. Even if you wish to explore different techniques to see which works BEST for your project, this is a fairly easy and comprehensible technique to experiment with.
The role of the Business Analyst (BA) is generally understood as the stakeholder who is responsible for managing the software requirements. While it briefly adds who a business analyst is, the real role goes beyond that. BA implies from the brainstorming phase of the project to its decomposition. In each of these phases, BA plays a vital and diversified role in bringing an idea to life. However, the way in which the BA views the security aspects of software is the focus of this article.
Understanding about Data Protection Standards and Regulations
To start with, BA’s understanding of the software security standards and it’s applicability plays a bigger role. There are different data protection standards and regulations available in the world. GDPR (General Data Protection Regulation), CCPA (California Consumer Privacy Act), HIPAA (Health Insurance Portability and Accountability Act), PCI (Payment Card Industry), ISO27001 (International Organization for Standards on Information Security Standard) are some of them. These standards and regulations significantly impact the SDLC (Software Development Life Cycle) and corresponding IT-development processes of organizations that plan to roll out information systems’ projects. They also increase the complexity of the functional, non-functional, and technical designs associated with the various business and technical layers outlined in systems. It is a software engineering responsibility to follow basic data protection principles. However, as a BA, it is better to have an understanding of at least a few of these standards and regulations, because the data protection requirements need to be addressed in the planning stage of the SDLC and documented to avoid significant cost overruns and rework later in the SDLC process.
Accordingly, based on the client, the type of the project, and region the software is being developed, the standards which need to adhere may differ. However, upon the selection of one, more or none of the above standards, the specific security-related aspects will differ as well. Hence, the focus of this article is given to how a BA can involve in a generic Secure Software Development Life Cycle (SSDLC) without being specific to the aforementioned security standards. Yet, it must be highlighted that, if a project was undertaken under such a specific security standard, the respective specific security concerns must be addressed by the BA and the rest of the team members.
The SDLC Vs SSDLC
The SDLC is a framework that interprets the process used by organizations to develop an application from its initiation to its closure.
That being said, In general, SDLC includes the following phases:
Planning and requirements gathering
Architecture and designing
Release and maintenance
Simply, the SSDLC will be derived by applying software security aspects to each stage of the SDLC. Business Analyst’s involvement in the SSDLC is further detailed out in the subsequent sections
Generic Security Touch-points
As discussed in the overview, once software security aspects are applied to each phase of the SDLC, it’s considered as SSDLC. Therefore, security touch-points are introduced at each level of the SDLC phases.
The involvement of the security touch-points can be easily demonstrated by the
Gary McGraw’s influential touch-point model as follows,
(Swsec.com, 2020) Among these security touchpoints, the focus is given to the involvement of the BA.
BA’s Involvement in The SSDLC
Security enforced planning and modeling techniques
By praising the selected SDLC methodology; planning, and modeling techniques shall be carried out by deriving the scope into multiple modules and sub-modules which allows easy maintenance and easy management of them. More the modules and sub-modules were derived and separated, more the security of each module can be enforced individually (Rather following all-in-one concepts) for a better-combined security output once all the modules are functioning in a single place. Accordingly, the Business functional architecture of the system shall be designed to fulfill the aforementioned context.
A sample section of the Business functional architecture is attached below for a further illustration
Security Requirements Specification
Security Requirements in SRS
All the requirements elicited for the project will be documented in the Software requirement specification (SRS) document format. Functional and Non-functional requirements captured will be elaborated as spec points under each SRS maintained for each module.
A sample section of the SRS document is attached below for a further illustration
Accordingly, as part of the functional and non-functional requirements gathering process, security requirements shall also be captured and documented the SRS,
A sample depiction of a security requirement is attached below for a further illustration
Security Requirements in User Stories
Apart from the SRS, user stories documents will also be maintained for each sprint. Therefore, security requirements shall also be covered either as user stories or scenarios under the user stories to ensure focus on the security
A sample depiction of a security scenario of a user story is attached below for a further illustration
As an initial requirement gathering step, Use-Case diagrams will be used to identify interactions among actors in a system. In the same mechanism, Abuse cases (also called misuse cases) shall also be identified by modeling adversarial actions to the system
A sample depiction of an abuse-case is attached below for a further illustration
Evil User Stories
Evil user stories are equal to the standard user stories, yet they express what an evil-minded user (abusive user) would do in the system instead of what a standard user would do. These stories highlight what the system is not expecting a user to do. By understanding what a hostile user would do in the product, acceptance criteria and the scenarios can be developed against it to better defend against them.
A sample depiction of an evil user story is attached below for a further illustration
Security Enforced KB Articles
Once the development is done and ready to be deployed, in order to enforce the security in release and the maintenance; procedures and documentation will be used such as Deployment guides, user guides, support team guides, etc.
Privacy & Cookies Policy
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.