- Agile Planning Workshops
- Agile Requirements Modeling in Planning Workshops
- Agile Requirements Workshops in Context
- Additional Reading
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Agile Requirements Modeling in Planning Workshops
Requirements workshops have always had elements of agility. These workshops build and sustain collaboration among technical and business people, generate shared understanding and mutual trust, incorporate hard-nosed assessment of project tradeoffs, and strive to uncover just enough information to deliver value to all stakeholders.
You adapt requirements workshops on an Agile project by incorporating requirements exploration (modeling) within Agile planning sessions. At times, these modeling activities are more like workshops, in that they use a skilled facilitator who has thought ahead of time about how to orchestrate the participants' interactions to optimize outcomes. At other times, the modeling is more informal and ad hoc. In any case, requirements modeling is focused on the necessary and sufficient requirements for the requirements focus at hand: big-view, pre-view, or now-view.
Let's explore the Agile requirements modeling activities to incorporate at each level of Agile planning.
Product Roadmap Workshop
The product roadmap workshop is integral to developing and articulating your company's product strategy (see Table 1). Before creating your product roadmap, you need to understand your market and review your technology capabilities and trends. When your organization is ready to allocate and align people and money with a product development effort, it's time to conduct a product roadmap workshop.
Alternatively, you can conduct a product roadmap workshop for a team in flow that doesn't yet have a product roadmap. How does this happen? Some Agile teams begin their journey by getting into a rhythm of delivery (it usually takes three or four iterations). They have a product backlog (a list of work to be done) and a mental sketch of the product, but for only one release. Lacking an overall product strategy or vision, they begin to question the sequence of delivery and become concerned about the sustainability of the architecture. They're ready for—and need—a product roadmap.
The key requirements-related deliverables for your product roadmap workshop are the vision statement and the product roadmap. You also incorporate product management deliverables, such as market segments and competitive positioning, to help solidify your product strategy.
The product roadmap identifies product themes and the cohesive chunks of valuable features that the team needs to deliver in each time slice. These time slices will become releases in the product roadmap. The workshop's deliverables also feed the product backlog.
Inputs to a successful product roadmap workshop include an analysis of market needs and trends, competitive offerings, and critical time-based occurrences; the organization's business strategy; and technological, financial, and time constraints.
Table 1: Product Roadmap Workshop: The Essentials
|
Workshop Purpose |
Sample Requirements Deliverables |
Participants |
Timing |
|
Define the product's vision and scope. Identify the features to deliver for the entire product. Develop a product backlog. |
|
|
|
Release Planning Workshop
Teams benefit from having a time horizon with a narrower focus than the entire product. At the same time, teams benefit from a wider view than just the immediate iteration (sprint). A release planning workshop provides this perspective (see Table 2). You conduct this workshop for each release, roughly every 1–4 months.
Your key requirements-related challenges in a release planning workshop are twofold. First, you need to identify the requirements that deliver an overarching theme to well-understood users (personas). Second, you focus on balancing business priorities with architectural dependencies.
With an eye toward requirements, inputs to a successful release planning workshop include the product roadmap, a definition of team capacity and velocity, an analysis of the state of the product architecture, an awareness of requirements dependencies, customer priorities, the release date, and a working set of "doneness" criteria for the release.
Table 2: Release Planning Workshop: The Essentials
|
Workshop Purpose |
Sample Requirements Deliverables |
Participants |
Timing |
|
Identify what to deliver for a given release. Elaborate the product backlog; prioritize, estimate (at a high level), and prune the backlog. |
|
|
|
Iteration Planning Workshop
The timing of iteration-level requirements modeling activities is not as cut-and-dried as for other Agile planning workshops. You conduct requirements modeling as part of work-ahead planning for the iteration, as part of the iteration planning workshop itself, and throughout the iteration (see Table 3).
Table 3: Timing for Iteration-Level Requirements Modeling
|
Iteration Requirements Modeling |
Purpose |
|
Work-ahead (during the prior iteration) |
Select and prioritize backlog requirements that are likely to be chosen for the next iteration, size those requirements, and learn what you don't know about them so further analysis can be done prior to iteration planning. |
|
Incorporated within iteration planning |
Explore requirements details so you can estimate, task, and make a commitment for delivering a set of requirements for the iteration. |
|
Throughout the iteration |
Analyze requirements details as necessary so you have sufficient requirements knowledge to build, test, and demonstrate the requirements within the iteration. |
Before your iteration planning workshop, use iteration requirements modeling sessions to do some work-ahead analysis. This enables the team to have a productive and efficient planning session. During these work-ahead sessions, the team (or a subset of the team) will explore requirements for backlog items likely to be delivered in the next iteration, identify requirements details (for example, user acceptance tests, data attributes and their sources, external interfaces, quality attributes, business rules), determine which stories might need more research, explore requirements dependencies, and prune the product backlog.
In your iteration planning workshop, the team estimates, plans, and commits to delivering a set of backlog items (usually in the form of user stories). Your planning workshop incorporates short bursts of requirements exploration (that is, lightweight requirements modeling activities) so you can learn enough about the requirements to gauge the tasks and time each item will take. Your key requirements-related deliverable are "right-sized" stories—small, concise user requirements with clear conditions of satisfaction that fulfill the iteration's theme or goal.
Inputs to successful requirements modeling during iteration planning are the prioritized backlog, an estimate of team capacity and velocity, an understanding of the state of product architecture, an awareness of requirements dependencies, the iteration delivery date, and a working set of "doneness" criteria for the iteration. Table 4 summarizes the requirements-related essentials.
Table 4: Iteration Planning Workshop: The Essentials
|
Workshop Purpose |
Sample Requirements Deliverables |
Participants |
Timing |
|
Identify what to deliver for a given iteration |
|
|
|
During iteration planning, you tolerate some necessary incompleteness, deferring some details about what you'll test and code until you actually do that development work. Then, "just in time," you have conversations about the requirements you're building and testing, and conduct short requirements modeling sessions (what Scott Ambler calls "model storming").
At times, these modeling sessions warrant more formality. Perhaps the right stakeholders are unavailable. Maybe requirements details are unclear and need more in-depth analysis, or the requirements are complex and interconnected. In those instances, you schedule the modeling session and optimize time by planning a series of collaborative requirements modeling activities.
For example, a team member will step in as requirements facilitator and investigate key user roles or personas. She creates a lightweight profile of the persona's motivations and needs, targeting the current iteration. The facilitator then schedules a modeling session and kicks it off by having the team and relevant stakeholders review and revise the persona's profile.
Next, the facilitator leads the group through a listing and validation activity; they name all the iteration's stories and crosscheck them against the iteration theme and persona's needs. This activity often surfaces questions about the scope of the stories, which are resolved. Then the facilitator leads the group through modeling activities to specify the necessary data, state, and rules for stories. This approach reveals conflicts and overlaps in the stories, allows the product owner (customer) to clarify acceptance criteria, and exposes potential reuse of user acceptance tests.
By incorporating a light touch of forethought and pre-work, as well as using a skilled facilitator, the team saves time. Without this session, throughout the iteration team members' time is sapped by multiple interruptions to discuss requirements ambiguities and inconsistencies.
Regardless of whether you're conducting requirements as work-ahead, during iteration planning, or throughout the iteration itself, these Agile requirements sessions focus only on the requirements for your current (or next) iteration. They're informal (using whiteboards, flipchart modeling, sticky notes, and other low-fidelity tools) and require less pre-work than product roadmap or release planning workshops. Yet these sessions benefit from many of the patterns, design guidelines, and collaboration techniques I described in Requirements by Collaboration: Workshops for Defining Needs.