Requirements frequently make the top ten list of challenges that teams encounter. The agile community leverages stories as a robust way for communicating user needs to development teams. But we must know the story. How do we know what the users need? How do we capture it and communicate it?
In the spirit of Agile requirements, here is the User Story for the Expressing User Needs Stage:
User Story:
As an Agile 2010 Attendee, I like to learn more about eliciting and transforming user needs into something that our team can use as the basis for building and testing our product to deliver something of value to my end users early and often.
Reduce risks and rework by mastering dependencies in your product backlog. Learn the differences between process flow and process dependencies, identify story dependencies via state transitions and pre and post-conditions, detect data dependencies using interaction matrices, and elicit dependent business rules. Visualize delivery and development options with a minimal marketable features (MMF) dependency graph. Analyze and manage your dependencies, identify core functionality and delivery options, and gain a vital perspective on what to build and when to build it.
| Presenter(s): | Mary Gorman , Ellen Gottesdiener |
| Day and Time: | Monday, 09 August 2010, 09:00 - 12:30  |
| Location: | E-3 |
| Level: | Practicing |
| Presentation: | Link to Slides |
How do you capture your thoughts about a product so you can answer the developer questions at the release and sprint planning meetings? What tools let you weigh unexpected new feature requests? This tutorial introduces 7 connected thinking tools that take you from product purpose statement, through stakeholders'-motivations, in/out list, Kano's subjective product qualities, actors & goals and use cases to Jeff Patton's storymap, which serves as a 2-dimensional product backlog to the iteration/sprint planning meeting.
| Presenter(s): | Alistair Cockburn |
| Day and Time: | Monday, 09 August 2010, 13:30 - 17:00 |
| Location: | E-3 |
| Level: | Introductory |
Are we done yet? Many teams new to Agile struggle with how to know when their story or feature is complete. We introduce the importance of Acceptance Criteria and the Definition of Done. Why is it important to the Product Owner and the Delivery team? In this economy we want to make sure we are building the right thing! The key concepts of the game are: Velocity Doneness – Definition of Done Self Organizing Teams and Roles Time-boxed Retrospective The game is a hands on stress free way to learn. There will be lots of laughing, come join the fun!
| Presenter(s): | lisa shoop , Julie Chickering |
| Day and Time: | Tuesday, 10 August 2010, 11:00 - 12:00 |
| Location: | E-3 |
| Level: | Introductory |
It’s not easy to build the right product. People don't always know exactly what they need, want things that won't help, and don't imagine what’s possible. Further, most people aren’t born with the ability to speak naturally in user stories or concise requirements statements. So we must learn how to ask the right questions, draw out pertinent information and understand our customer's world. This session explores how to make the most of questions: different types of questions, when to use each, and signs that you need to probe deeper.
| Presenter(s): | Esther Derby |
| Day and Time: | Tuesday, 10 August 2010, 13:30 - 15:00 |
| Location: | E-3 |
| Level: | Practicing |
| Presentation: | Download Handout |
One of the most important decisions a team can make is deciding what features it wants to deliver, and when to deliver them. Delivering the wrong features too early can lead to failure and delivering them too late, or for the wrong market segment, can lead to a competitive disadvantage and lost sales. In this hands-on workshop, Cory and Luke will show you how to use collaborative play with customers to discover how they think and what they value, and use this information to effectively prioritize and release the features they want - when they want them.
| Presenter(s): | Luke Hohmann , Cory Foy |
| Day and Time: | Tuesday, 10 August 2010, 15:30 - 17:00 |
| Location: | E-3 |
| Level: | Introductory |
What happens when you take 4 designers, give them all the same design problem and challenge them to come up with a solution and document their entire process? This highly interactive panel takes a detailed behind the scene look at their process, including: research, IA/interaction design, wireframing/prototyping and visual design. Each presentation will wrap up with a time-lapse video of their entire process from start to finish.
| Presenter(s): | Todd Zaki Warfel |
| Day and Time: | Wednesday, 11 August 2010, 09:00 - 10:30 |
| Location: | E-3 |
| Level: | Practicing |
In this class you'll learn the mechanics of collaborative product discovery: a short intense collaborative phase that precedes a successful agile project. Discovery workshops leverage design thinking to move from product idea through to a backlog and development plan. In this class you'll fill your practice toolbox with dozens of practices to mix and match in a series of discovery workshops that involve stakeholders, users, and the whole team to build your product backlog, envision your product's user experience, estimate development time, and plan successful product releases.
| Presenter(s): | Jeff Patton |
| Day and Time: | Wednesday, 11 August 2010, 11:00 - 12:00 |
| Location: | E-3 |
| Level: | Introductory |
Agile teams are asked to build product backlogs, but little guidance is given on how to organize them. Many teams utilize simplistic formats for their backlogs, but often lose the strategic vision in the lists of stories. Ironically, the same teams use very effective visual task board formats for their iteration backlogs. What would the task board equivalent be for product backlogs? The answer is - Story Maps! In this session, learn the key concepts of Story Maps and how they visually present multi-faceted product backlogs. We'll work through a hands-on exercise building an actual story map.
| Presenter(s): | Paul Hodgetts |
| Day and Time: | Wednesday, 11 August 2010, 13:30 - 15:00 |
| Location: | E-3 |
| Level: | Introductory |
Behaviour Driven Development allows analysts, developers and testers to collaborate on a project together, producing well-tested, valuable code. BDD emphasises test-first as a way of learning more about the project. This pattern can be applied to analysis too! We work through some simple exercises and techniques for delivering the stories, features and projects that really matter, and provide developers with a clearer understanding of the value behind stories or features before they start coding.
| Presenter(s): | Elizabeth Keogh |
| Day and Time: | Wednesday, 11 August 2010, 15:30 - 17:00 |
| Location: | E-3 |
| Level: | Introductory |
Introducing an approach to defining and measuring business value that is simple, intuitive and built on 30 years of success. Forget user stories, points, velocity and all the typical agile terms associated with business value. Instead, learn how to clearly quantify business objectives and measure value delivered through a combination of lecture and hands-on exercises. The approach combines the principles of Evo with the practices of Scrum to enable teams to clearly define and report the value they’ve delivered each release to stakeholders in terms they’ve defined!
| Presenter(s): | Ryan Shriver |
| Day and Time: | Thursday, 12 August 2010, 09:00 - 10:30 |
| Location: | E-3 |
| Level: | Practicing |
A story should not exit an iteration until it is done, but to be done at the end of an iteration, **it must be ready at iteration start!** But typical agile processes often defer detailed requirements discussions and elaboration until Iteration Planning, or to the prior iteration. This JIT approach works well for many, but often fails in complex scenarios. **A new requirements approach is needed for complex projects**; this session will cover how to mature requirements in a decoupled pipeline, operating on a separate cadence from the development iterations.
| Presenter(s): | David Bulkin , Kevin Fisher |
| Day and Time: | Thursday, 12 August 2010, 11:00 - 12:00 |
| Location: | E-3 |
| Level: | Practicing |
This session will bring together a set of practices to help analysts support agile teams. Where analysts sit between the business and developers they can reduce collaboration, delay information arrival and mis-direct. An agile business analyst by contrast is an enabler and facilitator. The analyst must work with business stakeholders and the development team to ensure that information is available at the right time and fidelity. Information arriving too early can be wasteful due to depreciation while information arriving late increases the risk of re-work.
| Presenter(s): | Gary Jones , David Draper |
| Day and Time: | Thursday, 12 August 2010, 13:30 - 15:00 |
| Location: | E-3 |
| Level: | Introductory |
How comprehensive is your backlog? Does it include nonfunctional requirements? These are often ‘missing links’ in a product backlog. A holistic set of product requirements includes quality attributes, external interfaces, and design & implementation constraints. Some nonfunctional requirements don’t easily fit into the user story canonical format. We will survey practical techniques for agile teams to represent nonfunctional requirements and provide practice with a sampling of the techniques so you can understand how nonfunctional requirements are vital link in your backlog.
| Presenter(s): | Ellen Gottesdiener |
| Day and Time: | Thursday, 12 August 2010, 15:30 - 17:00 |
| Location: | E-3 |
| Level: | Practicing |
| Presentation: | Link to Slides |
Your Logo Here! |
Producer: Bob Sarni
Co-Producer: Ellen Gottesdiener