Author: Aditi Sharma

Aditi Sharma, CBAP and PMP, has over 13+ years of experience in Business Analysis and Project Management. She has experience working with stakeholders from different geographies in Insurance domain, be it Life, General, or Statutory. Currently, she is working in Sydney, Australia, and enjoying every bit of it.

How to Build a Story Map with Persona & User Stories

Written by Aditi Sharma on October 21, 2021. Posted in Articles.

Organizations build various products to achieve certain outcomes. These can be to help support the growth of the organization, achieve its vision & mission, customer delight, regulatory obligations or to respond to new possibilities. The interesting point here is that customer or the different persons that can be derived may benefit from these outcomes or may get impacted as a result of action taken to achieve these outcomes. Thus, it is imperative to understand the value that is being delivered to the customer in the form of a product or service, benefits, or features when a product is designed.

What is a Persona?

A persona is profile of a user which represents needs of the customer, problems that they may face and their attributes like age, preferred social media channels etc. They help us understand the market segment and target market for a product or service that the organization is looking to improvise or launch.

The personas are usually based on findings from research on end-users of a system, potential customer research etc. It is essential to not create personas on poorly available data or unrealistic assumptions.

Why use Persona?

Personas are depicted as a form of a written document with attributes like age, profession, style of living, preferred social media channels, buying behavior, demographic etc. Personas can be end recipient of a product or could be negative user personas to understand who explicitly not to take into consideration when developing a product. Thus, they are the “characters” of user stories. This persona documentation helps to drive conversations around the product features, delivery, output, expectations and what not to address which in turn connects the customer profile with value proposition in a cohesive manner. This is the foundation for creating compelling products and services the customers would want to buy.

For example, an attribute on the persona could be that the customer wants to connect anytime anywhere with the website of your organization. A potential solution is to provide live chat functionality leveraging chat robots to handle common FAQs when the staff is not available to directly chat to the customer in off-line hours.

Another example could be the system solution of providing hints, tips and online step-by-step guides to assist a customer who wishes to perform steps required to say, set up an adverting campaign on the adverting platform website on his own without having to interact with customer service staff on chat or email.

How to translate Persons to User Stories?

Once the customer goals are defined, we can start planning out the product features that would be required to meet those objectives.

Each feature can then be broken down into epics, which leads to smaller user stories and ultimately tasks. A popular structure used to document user stories is “As a [Persona] I want to [action] so that [goal]”

What is a Story Map?

Story mapping is a visual exercise to capture the journey a customer takes with the product including activities and tasks they perform with the system to achieve certain goals or objectives. This helps teams to define work, identify holes and omissions, plan releases by assigning priority to stories/tasks in order to formulate plan of action.

There are a few models that can help the team in prioritizing namely,

Stack Ranking
Kano Model – Customer Dimensions of Satisfaction and Investment. Features in 4 categories: Performance, Must, Attractive, Indifferent
MoSCoW Model – Must-have, Should-have, Could-have and Would-have features
Cost of Delay – How time would impact outcomes

Conclusion

In order to maximize the value you deliver to customers, creating customer persona goes a long way. It is a critical step to put planning before product design which ultimately leads to a product which addresses the customer needs leading to greater uptake, loyalty and acceptance.

3 Tips to Engage Stakeholders

Written by Aditi Sharma on November 12, 2018. Posted in Articles. 1 Comment on 3 Tips to Engage Stakeholders

One of the most common challenges a business analyst faces is engaging stakeholders in various elicitation activities.

Effective stakeholder engagement is mainly based on human element of awareness, clarity, and resistance to change. This article examines common causes of lack of engagement and remediation steps to be undertaken in the preparation phase for elicitation sessions. Note that some of the topics discussed here may also be applicable when elicitation is being conducted.

Engagement empowers stakeholders to think, feel, and respond with motivation to connect deeper with objective and purpose of preparatory sessions for elicitation. Let’s examine some of the common causes which prevent stakeholder from becoming a partner on the project. These causes make it difficult for Business Analyst to gather preliminary information without much delays and to request stakeholders to do some initial analysis prior to conducting elicitation sessions. Such preparatory activities are necessary to get the best outcome possible from elicitation sessions.

Resistance to change

Technical and social variables of a change can be thought as two sides of the same coin. Former refers to making alteration in the way a work is performed and latter refers to the way this alteration is changing the established relationships in the organization. Social variable results in determining how well it would be accepted by involved stakeholders.

Team often resists change when they are not clear about how it affects their work, when they are not aware of the need for the change and when they are not involved in decision leading to the change. Constant engagement and information sharing is necessary to keep the team across different themes.

Lack of awareness about change

A change could have been tabled to provide simplified and faster customer experience, to achieve operational efficiency, to address complaints or regulations, to increase market share, etc. This change can result in amendments to business processes, IT systems or both. This usually implies that this change would impact ‘business as usual’ for some stakeholders. If the impacted stakeholders are not aware about the WHAT, WHY, WHEN and HOW of this change, then they are more likely to prioritize their ongoing work over any preparation task or exercise requested by business analyst. Thus, constantly reiterating the business value is imperative for providing clarity and transparency.

Lack of clarity on roles and responsibilities

Clearly defining roles and responsibilities of individual team member and shared responsibility amongst few team members increases accountability, and results in quicker resolution of impediments and decision-making. Not addressing this leads to confusion, frustration, and possible duplicate effort spend on shared items.

Let’s now try to understand few possible solutions to engage stakeholders.

Handling resistance to change

As mentioned in preceding section, both technical and social variables of a change must be addressed to reduce resistance towards change. Main responsibility to address this would be with relevant business unit. Business Analyst can support sponsors to ensure information about the change and support measures are properly communicated to impacted stakeholders. When stakeholders are aware about the change, its need, know who can help them in answering questions, how to raise their concerns and how to document issues, they understand change better and may even contribute towards making it more effective and efficient. Keeping it simple, easy and approachable are key concepts. For example, instead of multiple emails and too many meetings on various aspects about the change it could be worthwhile to drive towards specific and limited forums.

Provide visibility about change

Change could mean new ways of working, new team structure, new process, new procedures, new tools, new techniques, and so forth. Change could be driven due to new strategy, vision and mission of the unit or company. If stakeholders are aware of the reach, priority and impact of this change on unit or company, they will be in a better and informed position to assign priority to it over the other BAU activities. They will not perceive work requests related to the change as burden and would be motivated & empathetic towards reaching the set goals and objectives.

Clarity on roles and responsibilities

It is important for stakeholders to be aware about their roles and responsibilities to support the change including the degree of active or passive participation required from them. RACI (Responsible – Accountable – Consulted – Informed) matrix is a good way to document and share with the team. Lack of clarity on roles and responsibilities can lead to reduced interest and assigning incorrect priority to tasks.

To conclude, clear communication is key to get stakeholders involvement in various activities encompassing change implementation and sets everyone on the right path. Business Analysts supports in fostering a collaborative and safe environment for the team to thrive and work towards shared goals.

Is your Learning Curve like a School Bully?

Written by Aditi Sharma on July 12, 2017. Posted in Articles. 2 Comments on Is your Learning Curve like a School Bully?

One of the most difficult things for a business analyst to undertake is moving from a business domain where the Business Analyst has significant experience, into a new business domain where they have little or no experience.

The first few days for the Business Analyst in this new business domain sector is typically reserved to grasp and understand the ‘new’ business domain.

The expectations are high from Project Managers and stakeholders. The Business Analyst is expected to hit the ground running. To avoid getting lost in this transition from the old business domain into the new business domain, the Business Analyst can keep these four tips in mind to quickly learn a new business domain.

1. Search Far and Wide

Go far and wide by looking at Domain specific websites, Government Regulatory Bodies, Training Manuals, Intranet, Google searches, or any knowledge sharing depository in your company. Start looking for valuable information. You may find an Excel calculator or testing results with screenshots explaining a few process or system behaviors.

Skimming through technical documentation can reveal information about different system interactions, system boundary, input/output file, and so on. For example, reading about Redbook API or RMS API or Payment Gateways would help you to understand the constraints and boundaries within which the existing system is expected to function.

Don’t forget to write it down for later reference. Quick notes and diagrams can jog your memory.

2. Speak Up and Volunteer

Let your team know that you are ready to learn and to lend a hand where possible. Your team members may have creative ideas to use your skills. For example, helping to put together a presentation for a senior sponsor would provide an opportunity to learn more about business and stakeholders. It would also give the Business Analyst the chance to build and strength stakeholder relationships. This engagement can help you gain valuable information and connections.

Get in touch with change management team. Armed with a wealth of information such as Training Manuals, User Guides, and previous communications to users, the organization’s change management team is helpful in quickly learning the new system. Even if these documents are not the latest versions, they will provide insight on the way systems works and are often rich in screen shots & diagrams. Discover more about the organization’s hierarchy by looking at the creator, author, or approver names on these documents. Using this technique can broaden your list of people to speak to and gain valuable information.

3. Scenarios & Customer Point of View

You can always try to gauge how business and processes need to react when a customer (“Human Actor”) approaches with a certain request. That helps to build on the scenarios on which you can build understanding quickly since you can pretend to be the ‘customer’ requesting information in these scenarios.

You can perform scenario analysis using “use cases” technique to write down different scenarios and get that reviewed by peers / Subject Matter Experts. You may draw use case diagram during this phase. However, this would have to be supported by narrative (e.g. actors, trigger, pre-conditions, post-conditions, normal scenario, alternate scenarios).

For example, if you are expected to document high-level requirements for a new customer banking portal, look up what is offered by different banks to their customers and create a list of potential enhancements for items you feel are missing. Using this benchmarking approach of comparing your organization’s capabilities with those of the organization’s competitors gives you a deeper understanding of the system even if you haven’t worked on a banking project previously earlier.

Use a Gemba approach or respectful observation. Put yourself in your customer’s shoes and walk through the process from beginning to the end. Get a feel for the ups and downs a customer experiences when dealing with the organization.

4. Look for Patterns

A Business Analysts experience in dealing with processes, issues, and solutions would help in the journey of exploring and discovering this new business domain. Using your experience with a capability such as a fee calculation in a previous business domain can be used by the Business Analyst in the new business domain where similar calculations. Exception handling, error handling routines, mathematical calculations and other functions learned in one business domain can be applied to the new business domain.

You can also group or link similar issues or stories together to build the bigger picture in a current project. That would help you trace the hanging parts together. This is especially useful when working with data in the data analyst role. For example, if you have worked on outbound documentation earlier, then you would be familiar with the involvement of different teams – legal, content, business, development, mail house, etc. – when working on adding new capabilities to your project. This would help you to understand where to look for information and who can provide what for bridging the gaps. This in turn builds up your understanding of this domain and linking it to the bigger requirement.

Summary

Eliminating the learning curve is of course not possible. However, the tips above would help you in channeling your time and efforts in a more structured way allowing you to wade past the tides of the new work and challenges that this new project throws at you. Being proactive and not holding back would add to your credibility, knowledge, and experience rewarding you with more opportunities and referrals enhancing your career further.

An Approach to Requirements Elaboration in an Agile Environment

Written by Aditi Sharma on August 17, 2015. Posted in Articles.

Requirements gathering is the cornerstone to the success of any Agile project. There is no denying the fact that stakeholders often struggle in providing the functions and features that they expect from a system but rather provide the details and system behaviour. The key to achieving clarity is progressive elaboration. Interviews and workshops with stakeholders conducted by the business analyst can achieve this progressive elaboration.

Agile projects often use user stories, which act as the starting point for further refinement in terms of requirements elaboration, design, risks, and costs. User stories are usually captured using informal techniques and as such are not available to all the team members until it is segregated and scaled to fit in traceable stories. The use of informal techniques suggests the need for an elicitation process and a supporting tool that helps to share the artefacts as and when they are created, reviewed and approved.

Most organizations would need to invest in tools to support the Agile way of working. To be effective, the tools should be used to create a virtual platform to connect teams to each other. They can then use the tools to share information, keep it up-to-date, track and review information packets, and to keep the momentum of the project without losing focus and pace of deliverables. Utilizing this tool leads to real-time sharing of information and better transparency and visibility of workloads and ultimately, of the schedule.

If teams adopt the above-mentioned way of working then a few potential issues get addressed early in the project lifecycle. These include issues like blocked information flow, use of old and redundant information, the blurred view of work items, and low traceability. Addressing these issues mitigates a lot of problems with which a business analyst (and other team members) may struggle. However, to address this completely from the business requirements point of view, the base has to be laid out properly and completely. This need puts requirements elicitation and elaboration in the spotlight.

As mentioned, requirements elicitation often starts in the form of user stories. At this level, it is comparable to an outline of the expectations from the system in terms of functions and features. Once the outline of expectations is created and agreed with stakeholders, the focus should quickly move to the elaboration activity. The extent to which detailing is required varies depending on the team’s needs, however, this elaboration activity must achieve complete and correct documentation of business requirements, design, its rationale, and traceability (since if a task does not trace back to a user story, then it is not required).

However, the requirements elaboration activity is easier said than done. Depending on the stakeholders involved, different tools and techniques may have to be applied. Unlike in a traditional project where the requirements elaboration phase consists of detailed analysis and complete specification document, in Agile, this is done differently. The requirements elaboration phase of an Agile project focuses on identifying the user stories first, then detailing them as the project moves ahead. Essentially, the elaboration activity initially concentrates on high priority features and then progressively incorporates details. Storyboards and prototypes are powerful ways to gather feedback and quickly incorporate it. Allowing users to see details early on reduces rework costs since integration with other systems has not yet been done.

Since further iterations of elaboration build on user stories, the business analyst should ensure that certain key information points are captured upfront while creating the user story, avoiding the need to re-visit these stories later. Key information includes actors, pre-conditions, triggers, benefit, acceptance criteria and if possible, non-functional requirements. Ensuring the capture of these data points early in the phase helps build the understanding of the requirements and avoids the pitfalls that transform simple oversights into multiple issues at a later point in time. This data capture also allows the business analyst to start documenting the requirements using formal techniques and begin creating a document for review, sign-off and trace.

Another buzzword that comes up is “collaboration”. To understand this, think of scenarios where the business owner will probably provide his expectations on the system behaviour but leave the system design considerations to the technical teams. Collaboration is the essential thread connecting these teams. Any one team working in a silo is a recipe for disaster; we need open communication channels leading to high levels of trust. The need for collaboration needs to be factored in by the business analyst. Note that requirements documentation may take any form – spreadsheets, documents, presentations, diagrams, use cases. The driving force here is not the format, but the content (what), context (when, where), and collaboration amongst different teams say, IT & Business Analyst and Business Analyst & Development team.

It may also help to elicit, elaborate, and segregate the “must have” requirements from “good to have” requirements early on. This information can be used for prioritizing in sprints considering business user needs and value, and from change management point of view. Readily available information translates to quicker turnaround times for next actions or decisions.

Being Agile during the requirements process allows projects to develop more efficiently by having work tracks running in parallel rather than waiting for fully developed requirements that may have little interaction with business and little opportunities for mid-course corrections. There are heaps of benefits compared to the traditional Waterfall way of requirement elicitation and elaboration. This definitely marks a big change in the way solutions are designed and delivered in shorter time frames by various organizations.

Data Flow Diagrams – Are They Worth It?

Written by Aditi Sharma on April 28, 2015. Posted in Articles. 1 Comment on Data Flow Diagrams – Are They Worth It?

A picture is worth a thousand words – somebody surely captured a lot in this saying. I am a Business Analyst and I write business requirements so where does this fit in? Well, it does fit in the context of all the diagrams that a BA can leverage to put forth business requirements in concise manner. In this article, let’s explore the world of data flow diagrams.

A neat and clear data flow diagram (or DFD) can depict a good amount of the system requirements graphically. Here, the system can be manual, automated, or combination of both. A DFD shows the inputs, outputs, and how the input data got converted to output data (by a process or calculation). Focus is always on the data and how it gets transformed. It can not represent timing of a data flow i.e. whether it constantly occurs in real time, once per week or once per month. There is also no indication of when a system would run.

In order to depict movement and transformation of data, DFD uses standardized notations. There are two commonly used styles of symbols, one set developed by Chris Gane and Trish Sarson and the other by Tom DeMarco and Ed Yourdon. The difference between these two styles is just on the drawing style and nothing else. Most people in western cultures read from left to right. Therefore, BAs create diagrams from left to right.

The below mentioned is the DeMarco – Yourdon set:

Circle – Process; can not create or consume data; start with verb
Arrows (Data Flow) – Data moving in or moving out
Rectangles (External Entity) – External entities to system and may or may not be part of the organization; data Source or data receiver
Parallel Lines (Data Store) – Data at rest; Form starting point of data model; data can be moved only by a process

Most business processes are complex enough to get encapsulated in a single DFD. Hence, sets of DFDs are used for this purpose. The first DFD captures the summarized process set or scope, and further DFDs decompose the processes in details. The first DFD is popularly known as “Context Diagrams”.

The context diagram defines the “context of the system” i.e. it defines how the business process or computer system interacts with its environment, primarily external entities. This diagram is best used in early stages of requirement elicitation and can aid in further probing of the requirement without losing focus. It can also be referred to at the time of system integration testing to verify and validate.

Since detailing is mentioned in further levels of the DFD, one can often wonder how much is enough? It is recommended to limit further detailing of a context diagram to three levels only. Hence, Context Diagram > Level 0 DFD > Level 1 DFD > Level 2 DFD and then stop. If you feel that the entire system is not getting captured in three levels, then go back to context diagram and check if it should be more summarized than it currently is.

One more concept to keep in mind while decomposing a context diagram is the conservation principle or balancing. This principle states that the input, outputs, and data flows of a higher-level DFD are to be conserved or balanced in the detailed DFD. For example, if a certain context diagram has input A and output B, then level 0 DFD will also have to have the same input A and same output B. This principle would ensure that faulty diagrams are not getting created as more process detailing is being achieved in further levels of DFD.

Also, keep in mind that as the requirement elicitation stage progresses, refinements to the DFD will occur. You can not create the perfect DFD in one go. Refinements happen in an iterative fashion as requirement understanding builds further.

There are many CASE tools available in the market that help you create readable, clutter free diagrams. Tools can help align notations, use straight lines and 90-degree lines, connect various data flows, balance or process naming convention and so on. All this enhances the visual appeal of the data flow diagram and makes it easy to browse. One more important concept is grouping related items together – the way swim lanes do in flow charts. Swim lanes partition the diagram into horizontal or vertical lanes that usually represent the entity that does the work of a process. These lanes help depict the related processes in an organized and clear manner. For example, lanes can depict how interactions happen between different department units participating in a DFD.

For some readers of this article, the notes mentioned could be a recap of what they already know. But the point is, how many of us still believe in using this simple tool in our requirement gathering activity? Most of the business analysts take data flow diagrams for granted and think that it is best left in university education, but that is definitely not the case. If you probe appropriately, you will realize that this structured analysis tool is used by the project team to draw their inference of the user cases. It can be used to check for completeness and, therefore, find missing requirements. They are also great in business process re-engineering projects since they provide a sneak peek of the processes in a simplified manner. Unfortunately, it is often the under utilized tool in the Business Analyst Toolkit.

The most remarkable feature of the wonderful data flow diagram is that they are simple, effective and easily understood, including by people from non-technical backgrounds who may not like overwhelming process depictions. Do use data flow diagrams liberally whenever you can on your next project or assignment!

Don’t forget to leave your comments below.