My exprience working with Agile and Scrum
This page is about my experience as an agile business analyst. 'Agile' and 'Business Analyst' are often considered to be conflicting words. Afterall, a major driver for agile, is to remove the time spent doing analysis, and focus on quick delivery instead. If you are delivering to a colocated customer, your requirements and development team are internal, then maybe you don't need a business analyst. But when your customer is external, your requirements are dictated by external entities or if your development team is remote, then you dont have the luxery of conituous feedback and your product had better do what the customer expected. This is when you need business analysis skills.
This article introduces 8 activities to the Scrum process framework. Seven are new and 1 (Backlog Grooming) is already well documented. The description of each activity is in terms of; their purpose, how they add to the quality of a delivered product and the role that the business analyst plays in each activity.
The complete process (containing these activities) is detailed in my book, Using Agile In A Quality Driven Environment, which is available from Lulu (Free Download and Paperback) and Amazon (Kindle and Paperback)
Elicit Business Needs
|
Responsible Actor – Business Analyst The business analyst is responsible for capturing business needs and deriving requirements for development and testing. The product owner supports business needs elicitation with additional information about the business.
Elicitation of business needs involves many steps for the business analyst. In addition to interviewing stakeholders, the business analyst: The purpose of the Elicit Business Needs activity is to specify business needs that are elicited from business stakeholders. These business stakeholders’ needs are captured in the product backlog as epics. Each epic describes a goal of the business in terms of what is needed, why it is needed and who needs it. Epics include any additional information that is useful to analyze the need and create requirements. During elicitation of business needs, user stories are derived from epics and use cases are captured in the model. |
Groom Backlog
|
Responsible Actor – Product Owner The product owner is responsible for prioritizing and preparing user stories for upcoming sprints. The business analyst and development team support prioritization by estimating effort and complexity of user stories. Starting with the highest priority user stories, the product owner identifies errors or missing information. The business analyst identifies what needs to be done to complete the user story, and moves on to the next story. Quality assurance contributes information about defects and their impact on the current customer experience. Ultimately, the product owner decides the order in which epics are to be delivered and which user stories are no longer needed. Epics are updated as business needs change. Obsolete user stories can be removed, duplicate user stories are removed, conflicting information is resolved and user stories updated. User stories are prioritized by order that returns most value while keeping the customer satisfied. Also known as backlog refinement meeting, the purpose of the Groom Backlog activity is to organize and clean the epics and user stories in the product backlog. |
Maintain Requirements
|
Responsible Actor – Business Analyst The business analyst is responsible for maintaining a model of the product. This model includes: business use cases, business activity, system use cases, system activity, system data and system architecture. These model components are organized into a business view, a system functional view, system logical view and deployment view. The model is maintained by the busienss analyst. Quality assurance uses the model to write test cases against a product build. The purpose of the Maintain Requirements activity is to keep a record of the product functions and data, so that the business analyst understands the changes to the software when new user stories are applied to the product. |
Design Architecture
|
Responsible Actor – Solution Architect The solution architect is responsible for changes to the architecture. The output from this activity is a set of hardware and software components that comprise a foundation on which the product is built. The system architecture is required by the development team. The system architecture is used by the business analyst to update the deployment view in the model. The business analyst may need to update user stories in the product backlog, to reflect changes that occurred as a result of new technology. Quality assurance will need to understand how architecture changes are going to impact their existing test cases. The purpose of design architecture is to maintain a system architecture and design that satisfies current and future system requirements. |
Define User Experience
|
Responsible Actor – UI Designer The UI designer provides guidelines for screens that are created or changed as a result of user stories. Guidelines are often in the form of mockups of a screen, or screen components and instructions for navigation between those components. The mockups include size, color, font and position of text and components that are on the screen. The product owner provides guidance and their opinion on the design. The business analyst updates the user story descriptions to include additional information about the UI design. Quality assurance uses information about the screens to add detail to test cases. The purpose of the Define User Experience activity is to specify changes to interface components. A product UI design is included with the user stories that impact the user interface. |
Test Build
|
Responsible Actor – Tester Testers use the acceptance criteria from the model and details in the user stories, to create test cases. Test cases describe a series of steps and the expected outcome(s) of executing those steps. The results of executing those steps are captured in the test case, as test results. When an unexpected test result occurs, quality assurance writes a user story detailing why the software did not behave as expected. The business analyst provides support to testing by answering questions that quality assurance has about the user stories. Defect type user stories should be traced to the epic from which the functionality being tested was derived. This implies that an epic can only be declared ‘Done’ once all of its features have been delivered to production. The purpose of the Test Build activity is is to validate that an incremental software build meets its requirements. The results of this activity will help determine whether a software build can be considered for production. |
Deploy Build
|
Responsible Actor – Deployment Manager The deployment manager is responsible for deploying an approved incremental build into production. Although the software in the incremental build is the same for all customers, the architecture to which this software is deployed may vary by customer. (For example 1 customer may be using a Windows based architecture and another using OSX or Linux.) The deployment manager needs to be aware of these variations in deployment and will have developed procedures for each variation. The business analyst and quality assurance supports deployment by ensuring that the release performs as expected. The purpose of the Deploy Build activity is to give a customer access to the features that are part of a validated incremental build. |
Document Release
|
Responsible Actor – Writer Inputs - User Story, User Interface The writer produces user instruction manuals from the user stories and from incremental build that is to be released. The business analyst contributes to the user instruction manuals by explaining the user stories. Quality assurance contributes to the user instruction manuals by explaining their findings during testing of the build. The writer identifies changes to existing user instructions from the user stories that were completed in the sprint. The writer executes the increment build in order to understand the user interface and document its usage. The purpose of the Document Release activity is to create instructions for using a released product. |
A diagram of the complete process is shown below, that includes a typical Scrum development life-cycle.
