Leveraging Agile User Stories Gathering
This article will discuss approaches to leverage Agile user stories requirements gathering with non-functional requirements and Enterprise Environment Factors.
Join the DZone community and get the full member experience.Join For Free
Referring to the common definition, Agile methodology involves discovering requirements and developing solutions through the collaborative effort of self-organizing and cross-functional teams and their customers. It advocates adaptive planning, evolutionary development, early delivery, and continual improvement, and it encourages flexible responses to change.
In general, Agile methods focus on the "how" of project delivery. The Agile method relies on gathering fast feedback, producing iterative releases, and being able to rapidly adapt the design plan to best meet the needs of users.
It uses a series of smaller units/activities of work for the project delivery. The Scrum Master or an Agile project manager assigns a series of delivery units in sprint cycles. The development team, business analyst, and testing team will also provide modifications or add deliverables during project iterating and continuously improve throughout the development process.
A series of delivery items can be documented as user stories, which are used as backlog items for a sprint cycle. it’s an easier and concise way for communication among the development and business teams. Can user stores replace the full business requirements in software development? We will discuss that in the following 3 typical project development scenarios.
Before we discuss the major difference and if the user stories can replace business requirements, we need to understand what the user story contains:
Here is a basic format for a user story:
As a < type of user >, I want < perform some tasks > so that < achieve a goal >.
In this format, it identifies a role (who, user, or business), tasks (how it is delivered), and a goal (what is required). I will not discuss details on how to compose a user story since there are lots of resources talking about that.
Requirements, usually it is from a business perspective, dictate how a piece of software should work. The “business” should include the end-user, service delivery unit, application hosting platform support group, organization project delivery standards office, and organization project management office. The requirement document emphasis on the project functions and features, and what the project will be built for, as well as the non-functional requirements and standards that applied.
In general, requirements documents are excessively detailed, containing information about project scope, functions, user experiences, risks, business processes, rules, organization standards, information privacy, and more.
In a typical user requirement document, it should include:
- Functional Requirements, which include validation rule, actors, supporting information/user interfaces, integration requirements, traceability matrix with business process, application security requirements.
- Non-Functional Requirements, which include quality level metrics, organization standards, business continuity & availability, accessibility, compatibility requirements, information privacy, and system security requirements.
- Other Requirements, which include master data and reference, data requirements, operational reporting requirements, analytical reporting requirements, re-usability requirements.
In a large scale project, the user requirement document should also elaborate on:
- Business processes, which describe the current business process and to-be business process, and roadmap
- Business Scenarios, which are derived from business processes and elaborate how roles respond to an alternate set of conditions. It includes processes, tasks, actors, activities, triggers, conditions, basic flows, alternative flows, and business rules. Usually, it’s documented as use cases.
- Context Model, which describes roles and responsibilities in relation to other organizations and individuals, as well as linkages and interfaces with the environment in which it operates.
- Conceptual Data Model, which represents the structure of the information about in-scope, high-level entities, and their relationships. It’s used to enhance communication with business information.
Align User Stories With Business Requirements
In Agile project development, user shorties can be used as input for functional requirements, but still are incomplete until other non-functional requirements and organization Enterprise Environment Factors (EEFs) are all addressed in user stories and follow the organization policies and processes.
Enterprise Environment Factors (EEFs) usually include all policies, practices, procedures, and legislation that exist both inside and outside of the organization that will impact the way you manage a project. It provides project/product standards, quality standards, government standards, codes of conduct, review and training records, support channels and communication channels, enterprise architect approach, and project management approaches.
The Project as Enhancement or Customization Based on Existing Solution
For the project as enhancement or customization based on existing solutions, the business requirements are usually coming from the end-users and focus on the how. In that case, business scenarios and processes are the same or similar to the existing business scenarios and processes. The project will focus on the concrete business scenario “change," process updates, or detailed tasks. In that case with Agile development approach, user stories will be used as requirements documents and focus on the how for development sprints’ cycles.
The Project as SaaS or COTS Solution
Software-as-a-Service (SaaS) is a cloud-based method of providing software to users and is also considered to be part of cloud computing. Cloud-based applications’ ecosystems extend the rapid, cost-effective deployments with more agile iterative development cycles. It supports SaaS users to subscribe to an application from the internet rather than host & install it in the local environment.
Commercial-off-the-shelf (COTS) software is a term for software products that are ready-made and available for purchase in the commercial market. Many organizations are relying more on COTS applications to supplement, enhance or replace proprietary systems. As typically COTS software, it needs to be installed, configured and managed in the user's environment. Whereas SaaS is something the end-user consumes, and the SaaS provider is responsible for configuring and maintaining.
The user stories for a SaaS solution could be provided straightly from end users’ perspective since the SaaS or COTS solutions’ features are provided by vendors and already built. The high-level roadmap, scope, and ready-to-build specifications will be less important than customization requirements.
However, a project is still a project. Whether you are building custom code, buying a COTS, or subscribing to a SaaS solution, business scenarios and processes remain relevant.
The Project as Custom Build, Modernization, New System, or Platform
User stories are an Agile approach to requirements that emphasize end-user value. It helps the non-technical end-users understand what progress the team is making and to prioritize work. However, using user stories as business requirements for developing a complex or major technology modernization project, user stories need to cover the project vision, scope, business scenarios, processes, actors, business context models, interfaces, and even conceptual data model, as well as other non-functional requirements, such as information privacy, security requirements, support model, user accessibilities, and user experience wireframes. The detail level also depends on Enterprise Environment Factors (EEFs) that provide the organization standards and guidelines.
In those projects, the user stories not only include functional requirements from end-users but also should include non-functional requirements from the organization and the system benchmarks. Furthermore, the user stories can be broken down into non-story format technical tasks that can be highly technical in nature.
In Agile development, it’s all about gaining faster releases, better innovation, more productive, and more customers’ satisfaction. By adopting agile processes and ways of working, it will be a challenge for any organization to leverage the fast release cycles and maintain the same detail level of project documentations.
User stories in an Agile approach are focusing on requirements for end-user value. It’s an easier and concise way to exchange information among the development team and the business client. However, user stories should not be the method to reduce the project quality or shortcut organization standards.
The proposed options need to be considered during the Agile project management. User stories can be used for describing the business scenario, business processes, context, and conceptual data models, which can eventually be broken into multiple technical tasks.
I hope you found this article helpful and thanks for reading it.
Opinions expressed by DZone contributors are their own.