requirements

Conference Presentations

It's About Products Not Projects: Product and Portfolio Roadmaps

If you are managing your portfolio using projects, and not products, you may be missing opportunities to deliver more business value to your organization. Product and portfolio roadmaps are a strategic tool that you can use to align business goals and value to product delivery plans. Ellen Gottesdiener explores the why's, what's, and how's of product roadmaps including the different types of product roadmaps, steps for building and sustaining product roadmaps, key planning inputs, who should be involved, and techniques for exploring and evaluating features along the roadmap. Roadmaps articulate how your products will achieve their vision, help uncover technology requirements, communicate to internal and external customers, and provide a sound foundation for planning. Learn how roadmaps can help you deliver the right products, address customer needs, and make tough choices that will deliver strategic value.
Ellen Gottesdiener, EBG Consulting, Inc.
The Right Question for the Right Requirements
Slideshow

How often have you gone down the road of developing software almost to completion only to discover new requirements that require significant design and coding changes at the last minute? Requirements analysis is not just writing down what customers say they want. It's about digging down and discovering what they need. Without real analysis, our requirements often end up as poorly defined lists, anemic mock-ups, and incomplete or inconsistent models. Jack Jones spotlights one simple technique to discover these needs: Ask "why?" When the customer states a requirement, ask "why?" to delve down a level to discover their real problem, need, or opportunity. You may find you need to repeat "why?" a number of times. Join Jack to explore the very real consequences of not comprehending customer needs early in the process, and practice better communications techniques to avoid unnecessary requirements and scope changes.
Jack Jones, KMI
Better Software Conference East 2012: Data Collection and Analysis for Better Requirements
Slideshow

According to the Standish group, 64 percent of features in systems are rarely-or never-used. How does this happen? Today, the work of eliciting the customers' true needs, which remains elusive, can be enhanced using data-driven requirements techniques. Brandon Carlson introduces data collection approaches and analysis techniques you can employ on your projects right away. Find out how to instrument existing applications and develop new requirements based on operational profiles of the current system. Learn to use A/B testing-a technique for trying out and analyzing alternative implementations-on your current system to determine which new features will deliver the most business value. With these tools at hand, you can help users and business stakeholders decide the best approaches and best new features to meet their real needs. Now is the time to take the guesswork out of requirements and get "Just the facts, Ma'am."
Brandon Carlson, Lean TECHniques, Inc.
Using Business Objectives to Design Better Products
Slideshow

When software products are late to launch, a practical solution is to drop features from a release while still delivering a product your customers will love. If part of your process is to tie business objectives to product features, you'll have at hand the information needed to decide how to proceed-as well as a guide to prioritize development efforts throughout the project. Joy Beatty explains how to elicit measurable business objectives from stakeholders. She demonstrates how to write statements that describe how a feature contributes to business objectives and ways to assign a business value to each feature. Armed with this data, stakeholders can compare features quantitatively, taking emotion out of scoping decisions. As a reminder of the techniques discussed, Joy shares a Business Objectives Model quick reference for you to take home and use in your requirements elicitation sessions.
Joy Beatty, Blue Ocean Services at Seilevel, Inc.
Tests and Requirements: You Can't Have One without the Other

The practice of software development, including agile, requires a clear understanding of business needs. Misunderstanding requirements causes waste, missed schedules, and mistrust within the organization. A disagreement about whether or not an incident is a defect can arise between testers and developers when the cause is really a disagreement about the requirement itself. Ken Pugh describes how you can use acceptance tests to decrease this misunderstanding of intent. A testable requirement provides a single source that serves as the analysis document, acceptance criteria, regression test suite, and progress tracker for any given feature. Ken explores the creation, evaluation, and use of testable requirements by the business and developers. Examine how to transform requirements into stories- small units of work-each of which has business value, small implementation effort, and easy to understand acceptance tests.
Ken Pugh, Net Objectives
Collaboration Workshops: Discover, Plan, and Prepare the Product Backlog

To deliver high-value products, your agile team must reach a shared understanding of prioritized stakeholder needs. Collaborative techniques are best for this type of work, but not all agile teams use them or use them efficiently. Some rely too heavily on written user stories or story maps and fail to address complex topics or resolve requirements conflicts among stakeholders. Ellen Gottesdiener outlines how you can systematically collaborate about the product backlog in nimble, timely workshops that give your team an open venue for working together to make complicated decisions. Ellen explores collaborative techniques for backlog discovery and preparation. She teaches you to use the Seven Dimensions technique to make sure you capture all product needs.
Ellen Gottesdiener, EBG Consulting, Inc.
Ready, Really Ready, and Really Really Ready Stories

Product owners create stories they believe are ready for development. Developers accept and then estimate stories that are not really ready to be started. This disconnect between being “ready” and “really ready” results in miscommunication and frustration. For example, story development can take much longer than original estimates because of the details and “sad paths” that were not expressed in the story. Ken Pugh describes how to turn vague acceptance criteria into specific acceptance tests. He explains how levels of detail in acceptance tests can help to more closely estimate the effort required by stories and shows how acceptance tests determine when stories are complete. With Ken, you’ll go through creating a “really really ready” story and examine when it should be created and who should participate.
Ken Pugh, Net Objectives
Specification by Example: Building Executable Requirements

Specification by Example is a collaborative approach for constructing executable requirements. Examples demonstrate how the system should operate through the eyes of its users and shows understanding of the application’s functions. Michael Connolly demonstrates the practical and easy-to-implement Specification by Example method which he uses to write user stories and acceptance criteria. This direct approach, in which requirements are elaborated via executable code, creates a solid communication bridge between non-technical and technical staff and managers within the organization. Eventually, these executable requirements become the basis for the system’s acceptance test suite. As a take away, Michael provides participants with a lightweight requirements document format and an acceptance criteria framework to help you translate written specifications into automation.
Michael Connolly, OPOWER
Adding Good User Experience Practices into Agile Development

Whose job is it to ensure that the user has a good experience with a new application? As agile processes are taught today, the user experience (UX) design practice is usually left out or at best described as an optional team role. However, the companies that build useful, usable, and desirable software know that UX is baked into the whole development process. Jeff Patton describes what user experience design is and isn’t, and how every person on the team has something to contribute. Hear concrete examples of how companies have adapted their UX practice to work well in an agile context and, along the way, discovered innovative UX practices that work better in agile contexts. Jeff explores pragmatic personas, guerrilla user research, design sketching, lightweight prototyping, and concept testing. Leave with valuable tips for adding UX practices and thinking to your agile process to help you get good user experience.
Jeff Patton, Jeff Patton & Associates
Optimal Project Performance: Factors that Influence Project Duration

Speedy delivery is almost always a primary project goal or a significant project constraint. To shorten project duration without sacrificing quality or budget, you need to know where to focus the team’s efforts. Mining the QSM database containing many quantitative metrics and numerous qualitative attributes, Paul Below shares the factors that have the greatest influence on project duration. While he’s at it, Paul debunks a couple of myths. For example, many managers consider team skill to be important in determining duration of software projects-not so. The most important factors are certain types of tooling, architecture, testing efficiency, and management/leadership skills, which Paul explores in depth. Learn a technique for normalizing your projects for size by computing the standardized residual of duration.
Paul Below, QSM, Inc.

Pages

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.