Agile Business Analysis in Flow: The Work of the Agile Analyst (Part 2)

• 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.

• 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.

• 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 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.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

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

• 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.

• 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.

• 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.