A Business Analyst’s Experience With Scrum

After 6 years working as a business analyst on agile projects I decided to document my experience with Scrum in a book titled 'Using Agile In A Quality Driven Environment'. My experience taught me that the Scrum process framework is not the complete story. Scrum does not identify roles for the business analyst, system architect, tester, UI designer or deployment engineers. Instead, the work normally performed by these roles is performed by the development team or the product owner. It is possible that the Scrum development team includes people with all of these skills, but the problem is that all the development team work is performed within a sprint cycle. The only activity that Scrum identifies outside a sprint cycle is maintenance of a product backlog (and even then it is not documented as an activity in 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 are 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. Instead, with Scrum, the development team performs the work normally performed by these roles. Scrum expects the development team to include 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 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 provide specific responsibilities in support of releasing software, 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).

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 and testing the incremental build.

Not shown in the Scrum process diagram:

• Outside of the sprint cycle, the product owner elicits business needs as user stories and grooms the backlog, in order to prioritize work for upcoming sprints.

• The incremental build is deployed to customers.

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 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 provides 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. The product UI design is provided with the user stories during sprint planning.

• 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. These extensions describe my experience of working with agile development teams in several different environments.

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 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 into the Sprint Cycle is continuous. The output from the Spring Cycle is incremental. (The diagram is not intended to show hand-offs from one role or department to another. Information is pulled into an activity, as necessary.) Three information repositories are added to the process (Model, Product Backlog, Sprint Backlog). Information may be added to, updated and extracted from these repositories, at any time. Two deliverables are shown (Incremental Build and Release).

The process assumes that acceptance criteria are adequate to test a software build. You may wish to add a test case repository to the process.

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 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 captured within the model architecture view. 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 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 documented 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 1 or more components in 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 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 what 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 are maintained within a Model, Product Backlog or Sprint Backlog or they may contribute to a product release or incremental build.

Not shown in the diagram, are repositories for project 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 a task that needs to be performed.

• 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 include use cases, acceptance criteria, and user stories.

• Architecture – 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 - Are 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 1 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 1 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 serves 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 is 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 or purchase my book from Amazon or Lulu.com. It is available for Amazon Kindle, in paperback, or as a free downloadable PDF file.

See my website http://www.lmunday.com for more information.

Author: Leslie Munday, Sr. IT Professional

Leslie is a Senior level Information Technology (IT) professional with expertise in Business and Systems Analysis, Process Analysis, Requirements Analysis and Project Management.

Previously, I published a book titled “Analysis Through Pictures”. This book details the knowledge, skills, methods and best practices that I used as a systems analyst, up to 2011. It shows how the Rational Unified Process can be used effectively, to produce quality software systems. I have been actively involved with the International Institute of Business Analysis. I joined the IIBA after they asked me to give a presentation about traceability. Since then I have presented an analysis model of the Business Analysis Body Of Knowledge, and published several analysis presentations to various business analysis organizations. My website is intended to share my analysis knowledge skills and presentations with anyone who is interested in learning about the role of a business analyst.