Part 1: The Big Picture

Chapter 4: Agile Requirements for the Program

Additional challenges faced that did not exist at the team level:

• Maintaining Vision and Roadmap – so that multiple agile teams can work to a common purpose
• Release Management
• Quality Management
• Deployment
• Resource Management – as team needs shift, so much their resources
• Eliminating Impediments

Component Teams vs Feature Teams

• Component teams are specialized in a very specific domain. Primary focus for component teams is on making this product extensible and reliable so that other teams can utilize it as easily as possible. ++ Used when individuals are not interchangeable, often due to highly qualified domain expertise or because the technology is highly specialized. ++ At scale, a single user feature could impact dozens of components, meaning that one feature would need to get prioritized on dozens of product owner’s backlogs – can very difficult coordinate.
• Feature teams focus on the experience rather than the technology/system ++ Can be more effective as backlog items don’t need to be passed amongst as many teams, making planning and execution leaner. ++ Challenges include concurrent access to code, needing to train the teams in several different technologies, and potential difficulties in reusing the built infrastructure.
• likely a mix is necessary

The system team is responsible for system-level testing to fill in the gaps that the product team cannot execute, quality assurance test the nonfunctional requirements, and integrating the solutions together. Product Management – Responsible for the end-to-end solution that brings all of the product teams together Program-level artifacts:

• Vision: ++ Describes what is to be built ++ Aligns the teams to a common objective ++ Not time-bound to allow focus on the WHAT
• Roadmap: ++ Sets priorities and is a high-level plan for implementations ++ A series of planned release dates ++ Each release date has a theme and prioritized feature set ++ Time-bound in order to show the plan of intent
• Features: ++ Describes the new things the systems will do, derived from the vision/roadmap. ++“Services provided by the system that fulfill stakeholder needs.” ++ Exist one level above requirements. Comprised of simple statements/bullets that communicate the full scope without getting too detailed. ++ Come to be realized by stories
• Agile Release Train: ++ Produces shippable increments at frequent intervals (60-120 days) ++ Time-boxed iterations and milestones. ++ Scope is variable.

Chapter 5: Agile Requirements for the Portfolio

For those enterprises that have hundreds or thousands of agile practitioners, they may need an extra level of governance that allows for tracking higher and higher levels of scope, scale, and abstraction: The Portfolio level. Portfolio Management Team makes decisions on: • Investments in and sunsetting of existing products/experiences • Investments in new products/experiences • Investments in futures – those investments that are necessary for future sustainability but do not deliver value today

Epics are:

• High-level, large-scale development initiatives that help to realize the value of an investment theme. The goal of an epic is to describe the vision and should not be overly specific so that it can drive conversation of what features should be included.
• Can be described with any form of medium (e.g. bullets, a couple sentences, a video, a prototype, user interface mock-ups, etc.)
• Typically owned by an investment theme but can be stand-alone.
• Broken down into features and then subsequently into user stories.
• Not directly testable/tested.

The goal of an epic is to describe the vision and should not be overly specific so that it can drive conversation for which features should be included. Breaking Epics into Features and Features into Stories reduces the level of too-early specificity and decreases overhead for those managing these artifacts. It also allows the teams to interpret the requirements in ways that are easiest to implement.

Architectural Runway and Architectural Epics:

• A system has architectural runway if it has the infrastructure to allow current and upcoming features to be implemented without excessive refactoring. It’s important to consider which infrastructures need to be developed now so that they can reliably deliver anticipated features.
• Architectural epics are used to implement the necessary technological changes in order to increase architectural runway. They should be implemented just like business epics: incrementally.
• If we run out of architectural runway, new features will not be able to be added without significant, short-sighted refactoring. Releases will slow and the system may become so unstable that it has to be entirely rewritten.

Part II: Agile Requirements for the Team

Chapter 6: User Stories

User stories are the building block of agile development. They are brief statements of intent that describe what the system needs to do and they should be small enough so that the team can implement several in each sprint.

User stories are typically written by the product owner but can be written by any user with sufficient domain knowledge. Regardless of who writes the user story, the product owner is the only person to accept and prioritize these stories in the product backlog.

User stories are very different from previously waterfall system requirement documents.

• They focus on the value so that alternatives can be discussed.
• They are short and easy to read. COMMON LANGUAGE is key.
• They are easy to estimate.
• They are statements of intent, not complete requirement documentation. More details are provided on a just-in-time basis.

User stories have three clauses (Who? What? Why?):

• AS A - Can be an internal stakeholder, customer, or even another system
• I CAN - WHAT we want the system to do
• SO THAT - WHY we want the system to do it

Additional context and detail can be provided with a user story, such as Acceptance Criteria, mock-ups, algorithms, spreadsheets, etc. It’s important to note that acceptance criteria are not tests themselves, but instead additional detail/context.

INVEST in good user stories!

• Independent – Should be able to be developed, tested, and potentially delivered on its own. It’s okay to have sequential dependencies, but each user story should provide its own unique value.
• Negotiable – User stories are not a contract. By writing user stories to be flexible, we allow for more effective problem solving and trade-offs in delivery.
• Valuable – the most important attribute! The value can sometimes be easier to articulate if written from the viewpoint of a different stakeholder. Be sure to focus on the experience rather than the function/system as it can be difficult for a single system to provide stand-alone value.
• Estimable – The benefit of estimating a story is in answering the “it depends” questions. By trying to estimate a user story, the team will extract any hidden assumption or undiscussed acceptance criteria. The Fibonacci estimating sequence (1,2,3,5,8,13,21…) is a useful tool for estimating because complexity has a non-linear relationship with size and release timing. Estimates are provided by the DEV TEAM, not the product owner, and are relative to other stories.
• Small – User stories should be small enough to be completed in a single iteration. Without such, it cannot provide value. Smaller user stories also tend to be less complex. Large user stories will always be more difficult to predict the completion timing. The expert “agilest always leans to smaller stories and then makes them smaller still.”
• Testable – Proper agile states “all code is tested code.” Writing the tests prior to development will help to ensure that a user story will not get into a sprint that it cannot get out of. “If a team knows how to test a story, then they likely know how to code it.”

One of the most valuable activities in agile is splitting stories. When in doubt, make it smaller!! Here are some common ways to split stories:

• Walk through the different steps through the flow. Each one can probably be its own user story.
• Ask “what is the simplest version that can possibly work? – Do that first.
• Find variations and split them up, whether that be by language, by business rules, or by how data is displayed. You don’t need them all first.
• Find ways to defer system quality standards, not for the long-term, but enough to get started and learn about the experiences.
• Avoid words like “manage” – it implies multiple functions that should be broken up.
• Deliver the non-happy path use cases in subsequent iterations.

But what do we do when we don’t know the best solution or experience or if we even have the proper technology? There is another type of story called a “Spike.” Like user stories, they are put into the backlog, estimated, and put into an iteration. Spikes are decision-making or learning exercises. They can help to discover a proper solution/experience, how long something will take, whether it should be built or bought, etc. They do not directly deliver user-value and so they should be used infrequently, only for the most critical and largest unknowns. Consider splitting the user stories up first and only use spikes as a last option.