Tag: Use Cases

We Don’t Need No Stinkin’ Code: Testing Software Requirements

Written by Karl Wiegers on January 27, 2021. Posted in Articles. 1 Comment on We Don’t Need No Stinkin’ Code: Testing Software Requirements

Someone once asked me when you can begin testing software. “As soon as you’ve written your first requirement, you can begin testing,” I replied.

It’s hard to visualize how a system will function by reading some requirements. Tests that are based on requirements make the expected system behaviors more tangible. Even the simple act of designing tests reveals many requirements problems long before you can execute those tests on a running system.

Requirements and Tests

Tests and requirements present complementary views of the system. Creating multiple views of a system—written requirements, diagrams, tests, prototypes, and so forth—provides a much richer understanding of the system than can any single representation. Some agile development methods emphasize writing user acceptance tests from user stories in lieu of writing detailed functional requirements. Thinking about the system from a testing perspective is valuable, but that approach still leaves you with just a single representation of requirements knowledge, so you must trust it to be correct.

Writing black-box (functional) tests crystallizes your vision of how the system should behave under certain conditions. Vague and ambiguous requirements will jump out at you because you won’t be able to describe the expected system response. When business analysts (BAs), developers, and customers walk through tests together, they’ll codify a shared vision of how the product will work and increase their confidence that the requirements are correct.

A personal experience brought home to me the importance of combining test thinking with requirements specification. I once asked my group’s UNIX scripting guru, Charlie, to build a simple e-mail interface extension for a commercial defect-tracking system we had adopted. I wrote a dozen functional requirements that described how the e-mail interface should work. Charlie was thrilled. He’d written many scripts for people, but he’d never seen written requirements before.

Unfortunately, I waited a couple of weeks before I wrote the tests for this e-mail function. Sure enough, I had made an error in one of the requirements. I found the mistake because my mental image of how I expected the function to work, represented in about twenty tests, was inconsistent with one of the requirement. Chagrined, I corrected the defective requirement before Charlie had completed his implementation, and when he delivered the script, it was defect free. It was a small victory, but small victories add up.

Conceptual Tests

You can begin deriving conceptual tests from user requirements early in the development process. Use the tests to evaluate functional requirements, analysis models, and prototypes. The tests should cover the normal flow of each use case, alternative flows, and the exceptions you identified during elicitation and analysis. Similarly, agile acceptance tests should cover both expected behaviors and exceptions.

Consider an application called the Chemical Tracking System. One use case, “View a Stored Order,” let the user retrieve a particular order for a chemical from the database and view its details. Some conceptual tests are:

User enters order number to view, order exists, user placed the order. Expected result: show order details.
User enters order number to view, order doesn’t exist. Expected result: Display message “Sorry, I can’t find that order.”
User enters order number to view, order exists, user didn’t place the order. Expected result: Display message “Sorry, that’s not your order. You can’t view it.”

Ideally, a BA will write the functional requirements and a tester will write the tests from a common starting point, as shown in Figure 1. Ambiguities in the user requirements and differences of interpretation will lead to inconsistencies between the views represented by the functional requirements, models, and tests. Those inconsistencies reveal errors. As developers translate requirements into user interface and technical designs, testers can elaborate the conceptual tests into detailed test procedures.

Figure 1. Development and testing work products derive from a common source.

A Testing Example

Let’s see how the Chemical Tracking System team tied together requirements specification, analysis modeling, and early test-case generation. Here are some pieces of requirements information, all of which relate to the task of requesting a chemical.

Use Case. A use case is “Request a Chemical.” This use case includes a path that permits the user to request a chemical container that’s already available in the chemical stockroom. Here’s the use case descriptionUse Case. A use case is “Request a Chemical.” This use case includes a path that permits the user to request a chemical container that’s already available in the chemical stockroom. Here’s the use case description.

The Requester specifies the desired chemical to request by entering its name or chemical ID number. The system either offers the Requester a container of the chemical from the chemical stockroom or lets the Requester order one from a vendor.

Functional Requirement. Here’s a bit of functionality associated with this use case:

If the stockroom has containers of the chemical being requested, the system shall display a list of the available containers.⦁ If the stockroom has containers of the chemical being requested, the system shall display a list of the available containers.
The user shall either select one of the displayed containers or ask to place an order for a new container from a vendor.

Dialog Map. Figure 2 illustrates a portion of the dialog map for the “Request a Chemical” use case that pertains to this function. A dialog map is a high-level view of a user interface’s architecture, modeled as a state-transition diagram. The boxes in this dialog map represent user interface displays (dialog boxes in this case), and the arrows represent possible navigation paths from one display to another.

Figure 2. Portion of the dialog map for the “Request a Chemical” use case.Figure 2. Portion of the dialog map for the “Request a Chemical” use case.

Test. Because this use case has several possible execution paths, you can envision numerous tests to address the normal flow, alternative flows, and exceptions. The following is just one test, based on the flow that shows the user the available containers in the chemical stockroom:

At dialog box DB40, enter a valid chemical ID; the chemical stockroom has two containers of this chemical. Dialog box DB50 appears, showing the two containers. Select the second container. DB50 closes and container 2 is added to the bottom of the Current Chemical Request List in dialog box DB70.

Ramesh, the test lead for the Chemical Tracking System, wrote several tests like this one, based on his understanding of how the user might interact with the system to request a chemical. Such abstract tests are independent of implementation details. They don’t describe entering data into specific fields, clicking buttons, or other interaction techniques. As development progresses, the tester can refine these abstract tests into specific test procedures.

Now comes the fun part—testing the requirements. Ramesh first mapped the tests against the functional requirements. He checked to make certain that every test could be “executed” by going through a set of existing requirements. He also made sure that at least one test covered every functional requirement.

Next, Ramesh traced the execution path for every test on the dialog map with a highlighter pen. The yellow line in Figure 3 shows how the preceding test traces onto the dialog map.

Figure 3. Tracing a test onto the dialog map for the “Request a Chemical” use case.

By tracing the execution path for each test on the model, you can find incorrect or missing requirements, improve the user’s navigation options, and refine the tests. Suppose that after “executing” all the tests in this fashion, the navigation line in Figure 2 labeled “order new container” that goes from DB50 to DB60 hasn’t been highlighted. There are two possible interpretations:

That navigation isn’t a permitted system behavior. The BA needs to remove that arrow from the dialog map. If you have a requirement that specifies the transition, that requirement also needs to go.
The navigation is a legitimate system behavior, but the test that demonstrates the behavior is missing.

When I find such a disconnect, I don’t know which possible interpretation is correct. However, I do know that all of the views of the requirements—textual, models, and tests—must agree, so there’s clearly something wrong.

Suppose that another test states that the user can take some action to move directly from DB40 to DB70. However, the dialog map doesn’t contain such a navigation line, so the test can’t be “executed:” you can’t get there from here. Again, there are two possible interpretations:

The navigation from DB40 to DB70 is not a permitted system behavior, so the test is wrong.
The navigation from DB40 to DB70 is a legitimate function, but the requirement that allows you to execute the test is missing.

In these examples, the BA and the tester combined requirements, analysis models, and tests to detect missing, erroneous, or unnecessary requirements long before any code was written. Every time I use this technique, I find errors in all the items I’m comparing to each other, quickly and cheaply

As consultant Ross Collard pointed out, “Use cases and tests work well together in two ways: If the use cases for a system are complete, accurate, and clear, the process of deriving the tests is straightforward. And if the use cases are not in good shape, the attempt to derive tests will help to debug the use cases.” I couldn’t agree more. Conceptual testing of software requirements is a powerful technique for discovering requirement ambiguities and errors early on.

Karl Wiegers is Principal Consultant at Process Impact. He’s the author of numerous books and articles on software development, project management, design, quality, chemistry, military history, and other topics. This article is adapted from Software Requirements, 3rd Edition by Karl Wiegers and Joy Beatty. Karl’s latest book is The Thoughtless Design of Everyday Things.

What Use Case to Use?

Written by Jenny Quillian on December 9, 2020. Posted in Articles.

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.

Summary

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

Written by Nick Stowers on May 14, 2020. Posted in Articles.

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 www.storiesonboard.com 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

Written by Leslie Munday on November 27, 2019. Posted in Articles.

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.

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 Scrum.org: 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).

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 4^th 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 Lulu.com as a free PDF file.

Writing User Stories When There’s No User

Written by Larry Blankenship on May 23, 2019. Posted in Articles.

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.