Traditional Analysis

Agile Analysis Adaptation

Attend project chartering sessions to define a vision, glossary, requirements risks, and product stakeholders.

• Design, facilitate, or participate in product vision and roadmapping workshops.

• Help your customer understand which roles and themes to best deliver in each product release.

• Help your customer and team identify logical groupings of value-based requirements, and use these groupings to create a product roadmap showing incrementally delivered requirements over time. These requirements often take the form of minimally marketable features, stories, or epics (i.e., large stories that cross releases), use cases (high level only), events, or a combination.

Review and modify a list of tasks, time, and delivery dates in a work breakdown structure plan developed by the project manager.

• Design and facilitate (or participate in) release and iteration planning workshops.

• Regularly prune the product backlog by collaborating with team members to generate a relative size estimate for backlog items.

• Conduct analysis "spikes" (short, timeboxed research stories) to elaborate on backlog items that need more analysis, researching requirements and their priorities.

Generate a SWAG ("S#*&-Wild-Ass-Guess") estimate of time, effort, or cost for each requirement in the specification or user requirements document.

• During iteration planning, together with the rest of the team, write down the needed tasks to deliver each user story, and estimate how many hours they will take.

• Share actual time usage information with your team so that the team can track progress via visual graphs ("information radars") such as burndown, burn up, or cumulative flow diagrams.

Traditional Analysis

Agile Analysis Adaptation

Plan how to elicit requirements using a variety of techniques.

• Use face-to-face, collaborative elicitation techniques (workshops, prototypes) as much as possible while avoiding techniques (interviews, surveys, documentation study) that require longer lapse times or interpretation.

Plan, design, and facilitate requirements workshops over weeks (or months).

• Plan and facilitate short, informal requirements modeling sessions throughout each iteration.

• Plan and facilitate product vision and roadmapping workshops and release planning workshops.

• Teach your customer about supplemental analysis models so that they can question, participate, critique, review, and approve them (this should be done in traditional projects as well).

• Sketch out prototypes and identify user acceptance test data in real time, while a story is being designed, coded, and prepared for testing.

Traditional Analysis

Agile Analysis Adaptation

Define the scope up front by using a set of requirements models as the basis for detailed modeling.

• Help your customer define the vision and the scope up front-at a high level only.

• Help your customer and team create lightweight models during product roadmapping and release planning. These models help customers carve out a value-based release schedule that balances business priority with architectural dependencies.

• Collaborate with architects and developers on design to ensure that requirements include the technical aspects of the product.

Develop analysis models for the entire set of requirements that are in scope.

• Help your customer and team develop stories (user stories as well as stories that incorporate or separately define quality attributes).

• Help your customer and team develop and extend analysis models that support understanding backlog items selected for delivery in an iteration-if and when needed.

Ask the customer to prioritize requirements using a ranking scheme. If the customer is not available, do the ranking yourself.

• Help your customer assign a business value and a ranking to each backlog item.

• Help your customer understand requirements dependencies that might warrant adjustments to backlog rankings.

• Question rankings based on goals or themes for upcoming release or iterations.

• Assist your customer and team to right-size high-priority backlog items that are too big to deliver in combination with other high-priority backlog items in the next iteration.

Traditional Analysis

Agile Analysis Adaptation

Write a requirements specification.

• Help your customer and team write stories (or if you're acting as proxy customer, you write them).

• Create doneness criteria for stories so that each becomes a well-defined, small piece of valuable software for delivery in the next (or current) iteration.

• Create user acceptance tests or sample input and output data for each story.

• Determine the form and format of documentation that is necessary and sufficient for requirements-related work-in-progress, handover, or product documentation.

Traditional Analysis

Agile Analysis Adaptation

Set up and run meetings to review and sign off on requirements documents, and help customers run acceptance tests after the entire product's code has been created.

• Meet with the customer and some team members to prune the backlog (once or twice each week).

• Participate in iteration demonstrations and listen to stakeholder feedback on the delivered requirements to learn the customer's real needs and determine how to adapt the evolving product.

• Plan and facilitate, or participate in, iteration retrospectives, and learn from the customer how you can help deliver value faster.

Communicate with developers or testers (or respond to their e-mails and calls) to explain information in the requirements document; attend or run formal requirements review meetings.

• Conduct just-in-time analysis modeling with customers and your team to validate the business value of each story and to ensure it will be delivered to the customer's satisfaction.

• Participate in daily stand-ups.

• Sit with developers and testers as they are building code and tests to explain the story and its doneness criteria.

Help testers create user acceptance tests, or run those tests, after the entire product has been designed, coded, and unit/system/integration tested.

• Define input data and expected results or specific user acceptance tests as part of defining doneness for each user story, iteration by iteration.

Traditional Analysis

Agile Analysis Adaptation

Establish the requirements baseline, document change control processes, and generate requirements trace matrices.

• Help the customer and team establish a product backlog and define the smallest necessary requirements attributes for each backlog item.

• Help the customer and team define "just enough" requirements tracing needed to satisfy external regulatory body expectations.

• Help the team determine simple, meaningful requirements mapping and organizing (features to stories, events to stories, etc.).

• Define simple, unobtrusive ways to trace stories, with the aim of capturing metrics that will be useful for reuse and promoting development efficiencies.

Attend or schedule change control meetings.

• Help the customer and team prune the product backlog continually (reprioritize items, break down stories, assign rankings, estimate size, and explore requirements dependencies that will impact architecture and therefore release planning).

• Help the customer maintain the product backlog items (on story cards on a wall, in a spreadsheet, or using an industrial strength agile requirements management tool) - or do this on behalf of the customer.

Traditional Analysis

Agile Analysis Adaptation

• Participate in milestone or project "lessons learned" sessions to find out what went wrong, what went right, and who is responsible for the problems. The project manager fills out the lessons learned template and writes the closeout document.

• Sit with your manager once or twice a year for a performance review, and get feedback on your performance, months or weeks later. Sometimes that feedback includes second-hand comments from your customer and team.

• Use acceptance tests, examples, sketches, simple drawings, and face-to-face communication to get feedback on your understanding of requirements.

• Participate in daily stand-up status meetings to hear the impact you are having on other people's ability to deliver.

• On any given day, as an item you committed to deliver is deemed done, show it to the customer to get feedback on it and confirm that the conditions of satisfaction have been met.

• Design and facilitate, or participate in, iteration and release retrospectives (every two or three weeks, depending on your iteration timebox) to learn what works, learn what to adapt, and collaboratively agree on one or two things to do differently in the next iteration or release. The goal is to learn, adapt, get better, and experience joy in your work.