Skip to main content

Tag: Use Cases

What Use Case to Use?

The Use Case is a standard tool in the BA toolkit, and like most tools they come in different shapes and sizes for different jobs.

During Business Analysis Planning it is important to identify the appropriate use case format for the project needs.  At the high end we have a multi-page highly regulated requirements template. The base model is a single actor and basic flow.  Between these is the textbook version with complex flows. This article looks at these use case formats and design influences to consider during your Business Analysis Planning.   

Use Case Formats

  • Simple Flow Use Case
  • Complex Flows Use Case
  • Highly Prescribed Use Case

Simple Flow use cases describe the interaction of a single actor along one basic flow.  This format can be used as the starting point for a more complex effort, as a placeholder for planning purposes, or as the final deliverable for a simple project.  This format is similar to a user story, with post conditions instead of benefits. 

Complex Flow use cases include alternate flows, triggers, business rules, post and exit conditions. The degree of complexity should be determined by the stakeholder needs and perspectives.  For business users the documentation must be readable so that they can follow and agree that you have captured their needs correctly.  For the architects and developers, the details must be specific enough to translate into units of development.  For the testing teams the documentation must provide clear inputs and outputs of success so that they can formulate test cases. 

Highly Prescribed use cases have a multi-page template with approved instructions to complete each section.   There are projects which require such discipline,  but I have also worked on projects where the template became the end rather than the means,  and the degree of detail slowed down the project and produced wasteful documentation.  

Design Factors

Use Case formats will be influenced by:

  • Funding model
  • Requirements complexity
  • Rate of change
  • Regulatory environment
  • Project methodology
  • Project phase
  • Build or Buy


Funding Model

Organizational funding models may impose a need for provide for detailed requirements well in advance of the project development phase, in order to compete for funding.  A use case that identifies all potential steps, alternate flows, business rules and usage estimates can be useful to assist with cost estimates.  Tight funding oversight models will ask for more detailed documentation than open models.

Requirements Complexity

Retail web pages for major sellers can be large and complex because of the product offerings, but the system requirements themselves are repetitive and reusable and changes easily delivered with a user story or simple use case.

A new system with complex requirements needs more detailed documentation than an informational web page.   A new system with many business rules needs detailed documentation and requirements tracing to ensure proper coverage.  Integrated systems need a degree of rigor ad traceability to ensure that front end changes do not break upstream or downstream systems such as integrated re-order or delivery systems. 

Rate of Change

The retail web pages are repetitive but require rapid changes to meet demand and marketing plans. The requirements documentation cannot stand in the way of rapid delivery. 

From another perspective, detailed requirements documentation that can be reviewed in the change management process can help slow down a rush delivery and prevent embarrassing releases.

Regulatory Environment

Systems that are governed by external regulations need detailed requirements documentation that can be read and understood by multiple stakeholders so that all affected parties are able to understand and approve the inputs and outputs of the system to be delivered.  Systems that collect personal information must be able to demonstrate that the correct information is being captured and the appropriate security will be in place to protect this information from misuse.

Project Methodology

Waterfall projects tend to require detailed requirements. Agile projects prefer minimal documentation, user stories, and simple use cases if any.  

Project Phase

Documentation detail may expand or contract during the project phases.  As discussed above, projects may require detailed requirements documentation for early feasibility and cost analysis exercise, but they may then drop down to user stories for the development and delivery.  Other projects may require only simple use cases to outline a concept, and then expand on the use case flows and details during the requirements phase.

Build or Buy

If the project includes a build or buy decision, then a simple use case format that can be transferrable to a matrix of acceptance and evaluation criteria will be most useful when comparing solution options. 


Use Cases are a valuable business analysis tool that come in multiple flavors.  As part of the Business Analysis Planning step the Business Analyst should identify the degree of rigor and detail that the project and the stakeholders require and select the appropriate use case format(s) to use during the project.

4 key activities for a Business Analyst in the Alpha phase

On one of my earlier blogs, I described what I thought are the 3 key activities a BA should be doing when they were in a Discovery phase of a project.

The feedback I received was positive so I thought I’d give, what I consider to be are the 4 key activities are for a BA in an Alpha phase.

So what exactly is an ‘Alpha’?

In the UK, the Government Digital Service (GDS) defines the phases in an Agile delivery lifecycle as; Discovery, Alpha, Beta, Live and Retiring the service. GDS also cover in detail how the Alpha phase works, but what’s not covered in the article is what each role in a delivery team does within an Alpha, including Business Analysts.

If you’re not familiar with the names of these phases, they are the same for pretty much all Agile project delivery. The most common themes I’ve come across are;

  • Concept, inception, iteration, release, production, retirement

Moving Discovery outputs in to an Alpha

Key outputs from the Discovery the BA should have been heavily involved in include:

  • Stakeholder analysis
  • Understanding and defining the problem
  • Starting the product backlog

Each of these outputs now need to be taken through in to Alpha by the BA and here’s how.


Stakeholder analysis – Use your stakeholder knowledge

An Alpha to me is the exciting part of the Agile delivery lifecycle as this is where you actually start putting ideas and concepts in front of users and you learn ‘how’ they will really interact with your product and get valuable feedback. To ensure you get as honest and realistic feedback as possible, it’s important to try and create as real-life scenarios as possible to test the prototype with users. To do this, the BA should use their knowledge of working with stakeholders in Discovery and take this in to the development of the prototype with the designers on the team. After all, if you were the BA involved in Discovery, one of your key outputs is understanding the users and their needs, and that includes the needs of the business. Therefore, armed with this insightful knowledge, you should work closely with the design team to ensure they also understand the users. 

Understanding and defining the problem – Keeping the product vision in view

During Discovery, the team will have (or certainly should have) defined the problem that needs to be fixed and from that, a product vision should also have been defined. Roman Pichler has an excellent article on how to create a compelling product vision which I highly recommend you read as well as all the other articles he has on his website. 

For me, the product vision is one of, if not the key outputs from Discovery and is something that should be visible and referred all the way through the delivery lifecycle. All too often I’ve seen the product vision put up on the team wall (or worse, in a folder on the Product Owners laptop) but no one seems to take any notice of it and it becomes just a part of the wall space along with user research findings, sprint boards, etc. To make sure the product vision stays in view, and you have wall space, have it beside your user story map (coming up in the next section). Pretty much everything that’s in your user story map should stem from the product vision, so keep them close together.

Starting the product backlog – Make sure prototypes stem from user needs (building your user story map)

How prototypes are developed is different for all teams but in my view, the quicker you get to an interactive prototype, the better. I’m all for sketching out designs to protect costs and save time, but only once a prototype is in the hands of users and seeing their interactions with it, will you start to get valuable (and workable) insights to develop the prototype further. And remember, as the BA, you’re going to start building the product backlog based on the findings and create your user story map. If you’re even half serious about being a Business Analyst, I don’t need to tell you the powerful impact of user story mapping but if you need reminding, here’s Jeff Paton (the guy who came up with the idea of user story mapping) showing you how to create one. 

Help the team design iteratively

Having your user story map on the team wall (or online if you are a in several locations. I recommend as a user story mapping tool) is a great way to galvanise the team and ensure what you’re doing aligns with the product vision (hence having the vision next to the map). As we know, agile delivery focuses on building products in an iterative way and this principle should apply to designing prototypes in Alpha. I quite often see designers go off and start building complex, end to end user journey. For this very reason, having a user story map will encourage the design team to not think too far ahead. After all, your map will have an ‘MVP’ (or Release 1 if you’re not comfortable with the term MVP) swim-lane where you’ll define as a team what features will (or might) go in the MVP and this is what the design team should be focusing on prototyping.

And finally…

Don’t misunderstand me, and this is based on the feedback from my ‘BA in a Discover’ blog, these are not the only 3 activities a BA will carry out in an Alpha and you will no doubt carry out more than this (e.g. writing the user stories for Beta, working with technical architects/software developers to ensure what is being designed and tested with users can actually be built, continually developing the backlog, etc) however I’ve seen projects where the BAs have not been involved much in the design process and this which has led to problems further down the delivery process. Remember, you as the BA are the bridge between the design team and the developers/testers!!

An Alpha (or iteration) phase can last several weeks and if you as the BA follow these activities, you’ll ensure the product is designed with the users in mind, in an iterative way, and that when you get to the Beta phase (blog coming soon), your product will be delivering the value defined by the product vision.

A Business Analyst’s Experience With Agile

I recently wrote a book detailing a customizable extension to the Scrum framework.

The following diagram provides an overview of the process described in that book.

BATimes Nov27 1

Figure 1: Extension To The Scrum Framework

This article provides an overview of the process and the reasons why I created it. If you find this information useful and want to learn more, I provide a reference to my book at the end.

1.       Introduction

Working as a business analyst on agile projects for 6 years, I have learned that the Scrum process framework does not describe the complete story.

I emphasized the word agile, to indicate that the one thing all of these projects have in common is short time-boxed development cycles (or sprints).

Scrum identifies three roles. The development team, product owner and Scrum Master. Scrum does not identify roles for the business analyst, solution architect, quality assurance team, tester, UI designer, deployment manager or writer. (These are roles that I am used interacting with on an agile project.) Instead, with Scrum, the development team is responsible for the work normally performed by these roles. Scrum assumes that the development team includes people with all of the skills normally associated with these roles.

Quoted from Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment. Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person. Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations or business analysis. Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

A problem with this Scrum organization is that all of the work performed by the development team happens within a sprint cycle. However, the artifacts produced by the product owner, business analyst, solution architect, quality assurance, writer and deployment manager, are not sprint based. In addition, the UI designer and tester activities are sometimes independent of a sprint.

This article describes activities performed outside of the sprint cycle and identifies the benefits that they bring to the implementation of a deliverable product.

My Experience With Agile Projects

In my experience, some agile projects included a Scrum Master and other times project team members perform the Scrum Master activities. The roles that all of these projects had in common are, a product owner (sometimes known as the product manager), a development team, and of course, a business analyst.

Most development teams were supported by a separate user interface design team and an independent quality assurance (QA) or testing team. Other roles that are outside of development include deployment and operations, solution architects and document writers. These roles may be assigned specific responsibilities that support software development, even when an agile process is employed.

This article contains an overview of the activities, deliverables and best practices for these roles as they relate to agile systems development. Each role is responsible for one or more activities. These activities are described from a business analyst’s point of view.

A Brief Overview Of The Scrum Framework Process

Scrum identifies five activities (ceremonies), Hold Scrum Standup, Plan Sprint, Develop Sprint, Review Sprint and Learn Lessons From Sprint (Sprint Retrospective). The artifacts identified by Scrum are, user stories, software components and an incremental build. User stories are managed with the product backlog and the sprint backlog. All of this work is performed within two time-boxed cycles (Daily and Sprint).

BATimes Nov27 2

Figure 2: Scrum Framework

User stories are entered into a product backlog. The product backlog is managed by the product owner. User stories are taken into the next sprint cycle during a sprint planning meeting. During the sprint cycle, the development team develops components for an incremental build. When all user stories in the sprint backlog are done, the incremental build is reviewed with project stakeholders. After the sprint is complete, a sprint retrospective meeting is conducted to identify lessons learned from the previous sprint. A standup meeting is held every day, for the development team to plan the next day’s work and review the status of user stories in the sprint backlog.

User stories may be generated as a result of the sprint review or sprint retrospective and entered into the product backlog.

Development of sprint backlog user stories includes building user and system interfaces, updating the system architecture, writing user documentation, testing software components, testing the incremental build and deploying software to the customer.

The Scrum framework does not show activities that are the responsibility of the product owner, such as eliciting business needs as user stories and grooming the backlog, in order to prioritize work for upcoming sprints. These activities occur outside of the development sprint cycle.

Epics are user stories that are too large for a single sprint. Tasks are the breakdown of user stories into manageable pieces of work.

2.       My Agile Experience As A Business Analyst

The process that is described below includes artifacts, roles, and activities that I have been involved with when working as a business analyst on ‘agile’ projects.

As a business analyst, I generally support the product owner by:

  • Eliciting business needs
  • Maintaining the user stories in the product backlog
  • Writing and maintaining project documentation
  • Modeling business processes and system requirements, architecture and data

In addition, the business analyst may be expected to support development by:

  • Assisting with testing, by writing acceptance criteria and confirming test case results
  • Attending Scrum ceremonies, including the daily standup
  • Supporting development as requested

As you can see, the BA may be expected to provide support to all activities in an agile development process. (I have even been asked to sign-off incremental builds prior to delivery to a customer.)

Team Logistics

A major factor that affects the Scrum process is the logistics (or organization) of the project team and its stakeholders. I have worked in environments with the following logistical makeup:

  • The customer is remote – When the development team does not have direct access to the customer, the product owner (or similar role) acts as a proxy for the customer. The product owner may be the only person on the team who has direct contact with the customer. In this case, they are fully responsible for identifying customer needs and priorities and for confirming the accuracy of the product details. The customer may only get to see the product when it is released.
  • The development team is remote – Many projects do not have access to a co-located IT department. Software development may be subcontracted to a development team at a remote location. If the development team is located in a different country, then direct communication may be restricted to a few hours a week.

I have worked with a development team whose working hours were offset from the customer by 36 hours per week. By the time I arrived at work on a Monday morning, the developers had been working for a day and a half.

  • Quality assurance is a separate department – The project does not have dedicated testers. Testers are part of a QA department that is a shared resource across all departments. The development team will test each incremental build, but no software can be released to a customer until QA has validated that the product meets the customer needs. Product acceptance testing occurs after the sprint is complete and prior to product release.
  • A team of UX experts designs user interfaces – To ensure that customers experience a common look and feel across the enterprise, all user interface design work is performed by an independent UX department. Product UI specifications (or mockups) are included with the user stories that are taken into sprint planning. The UI specifications may change during development, with the approval of the UI designers.
  • Product deployment is on a separate release cycle – The customer does not want any disruption to their business due to defects or problems with deployment. Therefore, deployment occurs at the customer’s convenience and only after user acceptance testing is done.
  • Product documentation is part of the product release – User manuals and release notes are only written against a release. Documentation is not necessary for an incremental build, and therefore it does not need to occur as part of a sprint.

Assuming the worst case, where all of these traits are affecting your development process, I documented the following extensions to the Scrum process to show how they affected my experience with Agile.

3.       Overview Of The Process

The process diagram assumes that all the above logistical items are affecting the development process. The process is customized according to your development environment. For example, if UI design is performed during a sprint as part of development of a user story, then the Define User Experience activity may be removed from the process.


The Activities

In the following paragraphs, I describe how to read the process diagram shown in figure 1.

There are 3 time-boxed cycles shown in the process; Daily Cycle, Sprint Cycle, Release Cycle, and a 4th region where activities are performed on a continuous basis. The activities shown in these regions are connected by flows that indicate artifacts passed between them. The flow of information is continuous and it is passed in increments. (The diagram does not indicate any hand-offs from one role or department to another.) Four repositories of information are shown. Information may be added to, updated and extracted from these repositories at any time.

Continuous activities:

  • Elicit Business Needs – Business needs are elicited from the customer and captured in the product backlog as epics. Epics are analyzed to derive use cases and user stories. User stories are managed within the product backlog. Use cases are maintained within the project model.
  • Groom Backlog – The product backlog is reviewed on a regular basis and user stories are prioritized. Backlog items may be approved for development, or removed from the backlog.
  • Maintain Requirements – Requirements are continuously maintained within the Model. Use cases are analyzed, user stories updated in the product backlog and acceptance criteria are derived.
  • Design Architecture – The system architecture is maintained as new technology is introduced and interfaces are changed. A model architecture view captures the system architecture. User stories are maintained in the product backlog to capture architectural changes. Model architecture diagrams may be used during development of sprint user stories.
  • Define User Experience – System user interfaces are updated from product backlog user stories. Mockups of the user interface design are taken into the sprint and may be updated as developers work on the user stories.
  • Test Build – Test cases are continuously developed from user story acceptance criteria, so that an incremental build may be tested as soon as it is available. Test results are captured as a result of testing an incremental build.

Sprint cycle activities:

  • Plan Sprint – User stories are taken into the next sprint backlog during sprint planning, according to their priority in the product backlog.
  • Develop Sprint – Each user story impacts one or more components of the product build. During a sprint cycle, all stories in the spring backlog are developed and an incremental build is produced.
  • Review Sprint – When an incremental build has been produced, it is reviewed with the project stakeholders. User stories may be updated in the product backlog as a result of demonstrating the results from the sprint.
  • Learn Lessons From Sprint – The final activity in a sprint is to hold a lessons learned meeting with all members of the project team. The results of the sprint are input to the meeting and action items may be created as user stories in the product backlog.

Release cycle activities:

  • Document Release – Each release includes instructions for the users and release notes. These documents, inform the customer what has changed since the previous release. Release notes and updates to user manuals are derived from a combination of the developed user stories that make up the release and from exposure to the software user interfaces.
  • Deploy Build – The product is delivered to the customer on an agreed schedule, so that deployment does not interfere with their business activities. Deployment may involve, stopping running software, installing to the customer environment, interfacing with existing systems, validating that the installation was successful and restarting the system.

Daily cycle activities:

  • Hold Scrum Standup – Members of the project team present their work since the last standup, their plans for the coming day’s work and impediments to progress. User stories statuses are updated in the sprint backlog.

The Artifacts

Artifacts are the things that are produced within the process. Artifacts may be maintained within a project repository, such as the Model, Product Backlog or Sprint Backlog. Other artifacts may be temporary and used to distribute information between team members. Artifacts contribute towards producing a product release.

Not shown in the diagram, are repositories for documentation, code, and test cases, amongst others.

 The process diagram shows the following artifacts as input to or output from one or more activities:

  • Needs – Elicited from the customer, business needs are analyzed into user stories for the product backlog.
  • Epic – Business needs are captured in the product backlog as epic type user stories. Epics are broken into user stories. They are not pulled into a development sprint.
  • User Story – All work performed in a sprint is the result of a user story. User stories result from; the analysis of epics, defects found during testing or may be created by the project team to capture work that needs to be done.
  • Use Case – Captures the business processes that are derived from business needs. They are maintained in the project model. Use cases are analyzed to produce product requirements, data and user stories.
  • Requirement – This is a generic term for behavior the system must exhibit. Requirements are documented with use cases, acceptance criteria, user stories and any other means the team uses to capture requirements.
  • Architecture – The combination of software, hardware and their interfaces that will host an incremental build. The system architecture is captured in the project model and used by developers during the sprint in order to understand the impacts software changes. The solution architect works with the development team to identify impacts to sprint user stories.
  • UI Design – Normally in the form of user interface mockups, the user interface design is attached to user stories in the product backlog. The UI Designer works with the development team during the sprint.
  • Acceptance Criteria – Derived from use cases, they detail behavior that the product will exhibit in order to meet its requirements. Acceptance criteria are used to create and maintain product test cases.
  • Component – A piece of software that is created or updated from a user story. Components are added to an incremental build during a sprint.
  • Build – An instance of the software application that is updated every sprint.
  • Build Test Results – Captured in the product test cases as the results of applying the test case to a product build. Each incremental build is tested against the user stories that were developed during the sprint.
  • Product – A validated software build that and can be deployed to a customer.
  • Usage – Refers to the customer experience with a product release.
  • User Instructions – Documentation is written for anyone who needs access to the deployed product.

The People

A role encapsulates a set of responsibilities performed by one or more people. A person may perform several roles. The roles that were previously identified, are the business analyst, product owner, solution architect, UI designer, development team, tester, writer and deployment manager. Each role is responsible for one or more activities in the process.

The Scrum Master is considered out of scope. Responsibilities of the Scrum Master as they relate to the process, are distributed across other roles on the project team.

The business analyst is responsible for the Elicit Business Needs and Maintain Requirements activities. They ensure that user stories are ready for the next sprint. They update user stories from the system architecture and UI design and provide support to development, testing and anyone using requirements. The business analyst works closely with the product owner to ensure the success of the project. The business analyst creates and maintains a model of the Requirements and the model Architecture view. They create User Stories, Acceptance Criteria.

The deployment manager is responsible for the Deploy Build activity. They support customer and product deployment at the customer location. The deployment manager creates the Product Release.

The development team ensures the success of each sprint. They are responsible for the Develop Sprint, Plan Sprint, Review Sprint, Learn Lessons From Sprint and Hold Scrum Standup activities. The development team creates Components for an Incremental Build and may create work items in the form of User Stories, for the product backlog.

The product owner is responsible for the Groom Backlog activity. They prioritize and ensure the accuracy of business needs and serve as a proxy for the customer and subject matter experts, and remove obstructions to development. The product owner creates Epics.

The solution architect is responsible for the Design Architecture activity. They maintain the hardware and software architecture of the complete solution. The solution architect creates the product Architecture, which is captured in the model Architecture view.

Quality assurance is a separate department within the organization that includes testers. They are responsible for the Test Build activity. QA ensures the quality of every artifact that is produced during the process including validation of all software builds. QA creates test cases from acceptance criteria and user stories. During validation of an incremental build, they populate test cases with Build Test Results.

The UI designer is a member of an independent User Experience (UX) design team. They are responsible for the Design User Interface activity. The UI designer produces user interface mockups (UI Design) that provide a consistent and efficient look and feel to the product user interfaces.

The writer documents clear, understandable and accurate user documentation that supports a product release. The writer is responsible for the Document Release activity. They create User Instructions for a product release.

4.       Summary

This article provided a summary of a process that extends Scrum by introducing roles that are responsible for business analysis, solution architecture, UI design, quality assurance, documentation, and deployment. It defines the artifacts that are the responsibilities of these roles and the activities used to generate these artifacts.

These activities are only necessary when the role exists in the project team. Where a role is not applicable to your situation, that role’s work may be performed by the development team instead.

Even if your project does not explicitly identify the artifacts described in this process, the development team probably performs the work described by the activity that produces the artifact.

The process may be customized for projects using Kanban, SAFe or LEAN project. Details are documented in my book, Using Agile In A Quality Driven Environment (A Business analysts Experience With Scrum).

For more information, you may download my book from as a free PDF file.

Writing User Stories When There’s No User

One of the first things most of us learn when we make the transition to Agile business analysis is how to write user stories.

If you’ve started your Agile journey, you’re probably familiar with the format: “As a , I want to so that I can
However, what happens if you don’t have a user, but instead are dealing with a system? When I started working in Agile, I didn’t have users to write user stories for, I had APIs and file transfers. The users in my case were the systems that would consume the output from other processes and create output used by other processes. 
I had to come up with a different way of thinking about user stories. The user isn’t directly involved in the process, or was involved so early in the process, that they don’t have much input or effect on it. I found it was hard to identify roles or user profiles to include in the usual format. This article is about how I learned to work differently to address that question.
When there isn’t a user, the purpose or value of the story has to become the focus. The system should always act the same given the same inputs, so there isn’t the kind of variation you would see with a human user. What becomes more important is the reason the story exists at all: the reason for the system to behave a certain way. Granted, the value of the story is important whether or not a human user is present, but it becomes more important in this case.
In my world, most of the requirements come from changes in state law or legislation, so the reason for a story is quite often to comply with regulations, or to provide required information to the state. In other cases, the department that handles reporting and inquiries from the state needs information to be processed in a certain way, but still doesn’t have direct interaction with the systems that do the processing.


In order to deal with this problem, I use a couple of different formats to write my user stories when a user is not the subject of the story: “In order to/for , the system .” I try to include the business unit or entity that has the objective in the first clause, as it makes the value of the story clearer.
So for example, I might write “In order for the state to process vehicle records properly and to provide efficient transmission, the system sends a valid driver’s license number with each record.” In this instance, the value of the story is that the state is able to process vehicle records properly. If I wanted to, I could go into more detail about that, but since all of the people in my team know why this is valuable, it’s not required. 
I can, and often do, provide details about the objective not being achieved as part of the story discussion or as part of the acceptance criteria. This story would probably be part of a larger epic describing what a valid record means for that state, listing all of the fields that need to be validated before a record can be sent. I might include the detail about the consequences of invalid records being sent at that level, since it applies to all of the data in the record. This story is one part of that epic, but keeps the focus on just one data element. I like doing things like this as epics because it’s easier in a case like that to combine stories or separate them to to organize the work.
Another way to write these, if you prefer, is to say “Because , the system . Again, I try to include who made the requirement necessary in the initial clause to make things very clear as to why the story is valuable.
After I discussed this with some of my fellow BA types, one said, why not make the system the user so you can use the usual format? For example “As a , I need to , so I can . This is a perfectly acceptable way of doing things. I do think it takes the emphasis away from the value of the story, which is why I prefer the first two formats, myself.
Once we’ve written the user story, most of us know that the next step is to write acceptance criteria and provide other information that the developers might need to implement the story. In this case, I would need to provide rules for identifying a valid driver’s license number for the state in question. I would also need to provide a set of acceptance criteria to give the developer a way of knowing when the story was complete. 
Most of the time this is in the form of use cases or a list of business rules that describe the incoming data, and what gets done about it in terms of error messages, logging, or other responses to the data. This might actually create an ancillary user story involving a human user, for example “As a state reporting specialist, I need to receive an email when a record is rejected by the state.”
Writing user stories is an essential skill for Agile business analysts. Focusing on value is one way to address “userless” user stories. While value is always important, it becomes especially critical when user behavior is predictable and definable.

Design Thinking for a Business Analyst

Design thinking is a concept that was first introduced back in the 1960s and has recently gained a lot of traction in the business world.

Adopted by many high-profile FTSE 500 companies such as IBM, Apple and Google to increase innovation and improve products and services, design thinking is becoming a part of everyday operations in organisations across the board.

What is design thinking?

Design thinking refers to the ‘cognitive, strategic and practical processes by which design concepts (proposals for new products, buildings, machines, etc.) are developed by designers and/or design teams. Many of the key concepts and aspects of design thinking have been identified through studies, across different design domains, of design cognition and design activity in both laboratory and natural contexts.’
Essentially design thinking revolves around gaining a deep understanding of the people that a product or design is being created for. It is widely accepted that there are five different phases of design thinking in no particular order;

  • Empathise with your users
  • Define users needs, desires, problems and your insights
  • Ideate by challenging common assumptions and creating innovative solutions
  • Prototype and start creating effective solutions
  • Test your solutions


What does this mean for BAs?

The very nature of a business analyst role is analytical, and this is unlikely to change, especially in an era of rapid digital transformation. However, this doesn’t mean that certain concepts of design thinking can’t be applied in practice to the role of a Business Analyst. Design thinking is in essence just another form of business analysis and many BAs will have used design thinking concepts in projects before. Perhaps the most common areas that business analysts can apply design thinking are scope definition, requirements elicitation and analysis and validation of decisions. The depth and length of the process will largely be depending on the scale and complexity of individual projects, and as organisations are becoming increasingly agile, so to will the concepts that business analysts are required to use.

Embracing design thinking

For business analysts embracing design thinking can allow them to become more analytical, user-centric and effective. By applying the skills and techniques developed as a BA and undertaking further education, this can also accelerate growth and career trajectory. Approaching a project with a purely business or analytical mindset will no longer be enough – for a Business Analyst, this could mean developing elicitation techniques, rhetoric skills, facilitation, and influence for a more effective project outcome.