Find the best solution, not a better way to do it the old way.
Requirements: The Old Way and the New Way
-
Upload
enfocus-solutions -
Category
Software
-
view
495 -
download
3
description
Transcript of Requirements: The Old Way and the New Way
0 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Title Here
Requirements: The Old Way and The New Way
1 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
John E. Parker • Chief Visionary Officer of Enfocus Solutions Inc. • Previous Positions
o President and CEO of Enfocus Solutions Inc. inception through February 2013
o EVP and Cofounder, Spectrum Consulting Group o EVP and CTO, MAXIMUS Inc. o Outsourced CIO for HSHS (Large Healthcare System) o KPMG Partner
• Expertise o IT Strategic Planning o Business Analysis o Recovering Troubled and Challenged Projects o Enterprise Architecture o Development Methodologies (Agile, Waterfall, RUP, Design
First, FDD, TDD) o Financial and Cost Benefit Analyses o Business Process Improvement, Reengineering, and
Management
Contact: • http://enfocussolutions.com • [email protected]
2 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Requirement Trends (2014 and Beyond)
1. Agile adoption will continue to grow at a fast pace and will significantly change the way requirements are developed and managed.
2. User Stories will become the de facto standard for solution requirements. 3. Paper requirement documents will be relics of the past; requirements will
be maintained electronically in backlogs. 4. Personas will be developed and maintained and used for developing user
stories and for gaining a better understanding of user needs and what is required for faster user adoption.
5. Solution scope will be defined using Features and will be monitored by EPMOs. Features will drive agile development, and be integral to portfolio management, business architecture and release planning.
6. More efficient and effective validation methods will be used to ensure the right product is being built and to reduce waste.
7. User stories will be developed collaboratively by Product Owners and the Teams. Traditional requirements analysts will go away.
3 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Requirement Trends (Continued) 8. Development of requirements will be defined collaboratively instead of using
traditional interviewing techniques that are used today. 9. More emphasis will be placed on Discovery. This will become key for driving
agile development 10. Better techniques will be employed to align projects with business strategy and
deliver better business outcomes. 11. Discovery will address what needs to change to address the business need or
problem (Impacts) . 12. Lean Startup Concepts such as Minimal Viable Product will be used to validate
assumptions, concepts, and ideas. Validating ideas through code will become too expensive and cause too many delays.
13. Requirements and Design processes will merge. Business process models (BPMN) and Prototyping will become widely used as visualization aids for documenting Features which will drive user stories.
14. Review and approval of requirements will be done electronically by stakeholders..
15. More emphasis will be placed on Transition Requirements as the BAs role focuses more on enabling business change instead of writing solution requirements.
4 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Requirement Trends (Continued)
16. More emphasis will be placed on Business and Stakeholder requirements. 17. The role of the Business Analyst will change significantly from what it is today.
The Business Analyst of tomorrow will be much more focused on enabling Business Change instead of writing solution requirements. The Business Analyst will focus much more on the core concepts of the BACCM. Analysts that have been focused on writing solution requirements will no longer be needed and will go away. Business Analysis skills are needed more than ever.
18. PMI will place much more emphasis on requirements and will likely offer a certification in Requirements Management and and add Requirements Management as a knowledge area. IIBA will focus much more on enabling business change when BABOK V3 is released this year. There will continue to be tension between the two professional organizations.
19. Agile Delivery tools will continue to grow. Five vendors will continue to dominate this market (JIRA, Version One, Rally, IBM, and Microsoft).
20. A new breed of tools such as Enfocus Requirements Suite™ will emerge for Agile Discovery which will focus on discovery and validation of features that deliver business value.
21. Organizations that have a strong product discovery capability will have a significant competitive advantage over organizations that do not.
5 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Business Analysis Core Concept Model
Core Concept Defini-on
Change a controlled transforma.on of an organiza.on
Need a problem, opportunity or constraint with poten.al value to a stakeholder
Solu-on a specific way of sa.sfying a need in a context
Value the importance of something to a stakeholder in a context
Stakeholder a group or individual with a rela.onship to the change or the solu1on
Context the part of the environment that encompasses the change
6 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Enabling Business Change
7 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Agile Adop-on and a Message to BAs
8 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Agile Adoption
• Data from Forrester's Q3 2013 Global Agile Software Application Development Online Survey indicates that a whopping 90% of all teams practicing Agile development have adopted Scrum.
• The 2013 VersionOne Agile Survey shows that 88% of organizations are now practicing some form of Agile development
• The 2013 VersionOne Agile Survey shows that over half (52%) are using Agile to manage the majority of their projects.
9 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved. © 2013 Forrester Research, Inc. Reproduction Prohibited
1. Improved quality (56%) 2. More opportuni.es for mid-‐course
correc.ons (56%) 3. Overall improved customer and business
sa.sfac.on (38%) 4. BeLer business-‐IT alignment (37%) 5. Improved .me to market (32%)
Agile: Top 5 Reported Benefits
10 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Agile is an effec-ve delivery process!
However, agile is not effec-ve for discovering what to build.
11 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Delivery Track Develop releasable soQware based on validated backlog items.
Dual Track Agile: Emerging Concept
Discovery Track Discover business and customer needs and generate validated product backlog items.
12 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Why the Discovery Track?
• Elimination of Features with Little or No Value—focuses on validating needs and achieving a good user experience.
• Less Rework—reduces the number of iterations to reduce time and costs. • Cost Effective Validation—validates ideas in the fastest, least expensive way. • Better User Experience—validates prototypes instead of coding to validate ideas.
Benefits of Discovery:
• Who is the customer? • What is the customers’ problem? • Who are the users • How will the solution help the user in their day to day activities? • How will solving this problem help our business? • How will success be measured?
Answers the questions:
To evaluate market opportunities, reduce new product risk, and put the right things on the product roadmap.
13 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Discovery Features & Impacts
Delivery Stories & Tasks
PPM Projects
Objec-ves/KPIs Enterprise Architecture
DevOps Builds & Releases
Agile Tool Landscape
TFS • Configura.on Management • Development Automa.on • Build Automa.on • Code Repository • Con.nuous Integra.on • Monitoring
Automated Tes-ng HPQC TESTCOMPLETE
14 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
PorUolio Management
Discovery Development Release & Transi-on Mgmt.
Transforma-on Must transi.on from managing tasks to managing value.
Must transi.on from wri.ng requirements to enabling business change
Must transi.on from waterfall to agile development
Adopt and implement agile prac.ces (DEVOPS)
Primary Work Unit Projects Impacts
Features Sprints Releases
Key Trend EPMO Transforma.on Dual Track Agile Scrum Kanban
Devops
Requirements Business Requirements Stakeholder Requirements Solu.on Requirements (User Stories)
Transi.on Requirements
Leadership &Teams
Por]olio Manager Discovery Manager Discovery Team
Product Owner Agile Team
Release Manager Release Team
Success Measure Successful Business Outcomes
Effec.ve Business Change
Valuable SoQware
Con.nuous Integra.on
Cultural Challenges
Integra.ng Business and IT PMOs will be challenging. Migra.ng from a task to value mentality will require new skills and training. Migra.ng from managing project to managing value streams will also be difficult.
This will be a new concept for many organiza.ons as they move from solu.on requirements to enabling business change. BAs will need to be retrained and develop new skills.
Moving from waterfall to Agile prac.ces will be difficult for many organiza.ons
Implemen.ng DEVOPS will be challenging for organiza.ons that are use to opera.onal stability with few changes
Agile Organizational Transformation
15 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
A Troubling Statistic for BAs
The 2013 VersionOne Agile Survey shows that product owners are getting more knowledgeable about Agile. Business Analysts have taken their spot at the bottom of the pack. Note to BAs: If you do not start learning Agile, then you better start preparing your resume or planning your retirement. If you plan on continuing writing solution requirements in the way you did in the past, they you are in for a rude awakening.
16 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Different Types of Requirements
17 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
BABOK and PMBOK Requirement Types • Business requirements, describe the higher-level needs of the organization as a whole,
such as the business issues or opportunities, and reasons why a project has been undertaken.
• Stakeholder requirements, describe needs of a stakeholder or stakeholder group. • Solution requirements, describe features, functions, and characteristics of the product,
service, or result that will meet the business and stakeholder requirements. Solution requirements are further grouped into functional and nonfunctional requirements: o Functional requirements describe the behaviors of the product. Examples include
processes, data, and interactions with the product. o Nonfunctional requirements supplement functional requirements and describe the
environmental conditions or qualities required for the product to be effective. Examples include: reliability, security, performance, safety, level of service, supportability, retention/purge, etc.
• Transition requirements describe temporary capabilities, such as data conversion and training requirements, needed to transition from the current “as-is” state to the future “to-be” state.
• Project requirements, describe the actions, processes, or other conditions the project needs to meet.
• Quality requirements, capture any condition or criteria needed to validate the successful completion of a project deliverable or fulfillment of other project requirements.
18 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Business Requirements
Purpose Business requirements are statements of the business ra.onale for authorizing the project. Business requirements include a high-‐level descrip.on of the soQware requirements using features that align to business goals and objec.ves.
Documenta-on Methods
• Vision • Problem Statement • Objec.ves • Impacts • Feature Defini.ons
Examples • Es.mates for Customers • Customer Invoicing • Payments to Contractors
Documents Documents that contain business requirements may be referred to as a project charter, vision and scope, business case, marke.ng requirements, statement of work, document of understanding, product vision, or project scope
Audience The audience for business requirement typically includes the project team members, the business team members, project sponsors, and other stakeholders involved in the project.
Project Risk Expected Business Outcomes will not be achieved.
19 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Stakeholder Requirements
Purpose Stakeholder Requirements are stated from the user's point of view and describe what is needed for the user to do his or her job. (Some.mes called User Requirements)
Documenta-on Methods
• Personas • Scenarios • Use Cases • Needs • Business Process Models • Prototypes
Documents Documents that contain user requirements are oQen called user requirement documents, opera.onal capabili.es, concept of opera.ons, use cases, or business process models.
Audience Users are the primary audience for the user requirements, however, technical staff can also benefit from understanding user needs and should review user requirements.
Project Risks User needs will not be met resul.ng in refusal to use the system or costly workarounds.
20 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Solution Requirements - Functional
Purpose Func.onal requirements describe product capabili.es—things that the product must do for its users or allow its users to do with the soQware. Func.onal requirements are the doing part of soQware—the ac.ons, tasks, and behaviors that users generally interact with.
Documenta-on Methods
• Shall Statements • User Stories
Examples • “The system shall provide the capability for schedulers to assign contractors to jobs in their local area.”
• “The system shall permit the inventory manager to search for available inventory items.”
• “The system shall no.fy the operator when the temperature exceeds the maximum set value.”
Documents Func.onal requirements are generally documented in a func.onal requirements documents, soQware requirements document, systems requirements specifica.ons or product backlog
Audience The audience for the func.onal requirements is developers.
Project Risks Costly rework, budget and schedule overruns, subop.mal solu.ons that deliver liLle value to the business.
21 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Solution Requirements – (Nonfunctional)
Purpose Nonfunc.onal requirements are proper.es that the product must have that may not be evident to the user, including quality aLributes, constraints, and external interfaces.
Documenta-on Methods
Usually documented as shall statements. Some organiza.ons have tried to use User Stories, but these do not work well defined as user stories.
Examples • “The response .me for loading all es.mate informa.on onto the screen shall be no more than six seconds aQer the user submits the es.mate request.”
• “During the peak holiday season between November 1st and January 5th, the inventory search capability shall permit 500 simultaneous users to search for inventory items.”
Documents Non func.onal requirements are documented in soQware requirements documents.
Audience The audience for non-‐func.onal requirements is developers.
Project Risks Costly rework, budget and schedule overruns, subop.mal solu.ons that fail to achieve service level objec.ves.
22 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Solution Requirements – (Transition)
Purpose Describe what is needed to transi.on from the current (AS-‐IS) to the the future state (TO-‐BE). Includes such things as data conversion and training requirements.
Documenta-on Methods
Usually documented as shall statements.
Examples • Data Conversion • User Access and Security Setup • Organiza.onal Change • User prepara.on and Training • Produc.on turnover and transi.on • Customer and supplier prepara.on and transi.on • Business Con.nuity
Documents • SLAs • Data Conversion Plan • Organiza.onal Change and Training Plan
Audience The audience for non-‐func.onal requirements is people involved in the transi.on team including: produc.on support and help desk, DBAs, Trainers, business management, and others
Project Risks Systems delays, customer service interrup.ons, costly roll-‐backs, and lack of user adop.on.
23 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
What Are the Expected Business Outcomes?
What Business Changes Need to be Made?
What are the Solu.on Components?
What do the Customers and Users Need?
What is Needed to Meet Stakeholder Needs?
How do we Transi.on to the New Solu.on?
Objec.ves
Impacts
Features
Stakeholder Requirements
Solu.on Requirements
Transi.on Requirements
Business Requirements
Types of Requirements
24 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Requirements Development and Management The Old Way and the New Way
25 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Requirements Change
The Old Way – Freeze Requirements Large requirement documents were prepared, reviewed and approved. The requirements were considered frozen aQer approval received.
The New Way – Baseline Features Individual features are baselined and placed into bundles represen.ng development itera.ons or sprints.
The New Way – Elabora-on through Conversa-ons Requirements are con.nually clarified and elaborated through conversa.ons held between developers and business SMEs. Design decisions are documented as requirement aLributes.
The Old Way – Everything Defined Upfront All requirement details were fully defined up-‐front.
From Frozen Requirements to Anticipated Changes
The New Way – Con-nual Process Requirements development and management is a con.nual process that mirrors the systems development lifecycle. Developing and managing requirements runs con.nuously through the life of the project. An.cipa.ng requirement change is part of the process.
The Old Way – Long Development Cycles Requirements were considered a phase of the development lifecycle. Requirements were developed up-‐front and given to development. AQer the requirements were approved, the requirements development phase ended.
26 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Requirement Documentation
The Old Way – Documents • BRD – Business Requirements Document • MRD-‐ Market Requirements Document • URD – User Requirements Document • FRD – Func.onal Requirements Document • UIRD – User Interface Requirements Document • SRS – Systems Requirements Specifica.on
The New Way – Data • Objec.ves • Impacts • Features • Stories • Sprint Plans • Releases
The New Way – Integrated Database Mul.ple disciplines working together to create an integrated requirement repository that includes business, stakeholder, and solu.on requirements.
The Old Way – Mul-ple Versions of Paper Documents A single analyst crea.ng versions of requirement documents in Word and then wai.ng for stakeholders to review and approve.
The New Way – Data Integra-on Requirement data is transmiLed to applica.on and tes.ng environments electronically.
The Old Way – Paper Documents Large paper documents were sent to Development for building and tes.ng the system.
From Paper Documents to Structured Information
27 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Business Requirements
The Old Way – Business Case for Funding Only Most organiza.ons prepared a business case to get funding, but the business case was never used aQer that.
The New Way – Living Business Cases Business Cases will be developed and maintained throughout the life of the project. They will also play a key role in benefits realiza.on.
The New Way – Success Measured by Business Outcomes Project success is measured by whether the project achieved expected business outcomes.
The Old Way – Success measured by Time & Budget Project success was measured whether the project was delivered all scope, on .me and on budget.
The New Way – Business and IT Accountability Business requirements will be developed and maintained collabora.vely by the business and IT.
The Old Way – IT Accountability PMs and BAs prepared business requirements with limited review by the project sponsor.
From Necessary Evil to Strategic Driver
The New Way – Strategic Business requirements will be key to obtain funding, delivering business value and achieving business outcomes.
The Old Way – Ignored Business requirements were oQen ignored or poorly defined. They were oQen viewed as a waste
28 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Stakeholder Requirements
The Old Way – Use Cases Most organiza.ons prepared use cases to capture stakeholder requirements.
The New Way – Personas and Scenarios There will be much wider use of personas and scenarios to capture stakeholder requirements.
The New Way – People, Process, and Technology Stakeholder requirements will now focus more broadly than just technology. They will define what people, process, and technology changes are needed to meet the business need.
The Old Way – Technology Use cases were developed to iden.fy what func.onal requirements were needed for the technical solu.ons
The New Way – Valida-on through MVPs ,Prototypes, and Simula-on Stakeholder requirements will be validated using more effec.ve methods such as building prototypes, modeling and simula.on.
The Old Way – Valida-on through Review and Approval Stakeholder requirements were validated through review and approval
From Use Cases to Enabling Business Change
The New Way – UCD and BPMN Defining stakeholder requirements will require business analysis, user centered design, and business process modeling skills.
The Old Way – Use Cases Use cases were defined, oQen with liLle regard to the business process. This oQen created subop.mal technology solu.ons that did not meet business needs.
29 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Solution Requirements
The Old Way – All Requirements Up Front All requirements were defined upfront and given to developers aQer approved by stakeholders.
The New Way – Just Enough Just in Time Requirements are developed con.nuously throughout the project. Requirements are defined in barely enough detail and elaborated through conversa.ons between users and developers.
The New Way – Collabora-ve Conversa-ons Anyone can draQ a user story. The user stories are refined through face to face conversa.ons between the user and developer.
The Old Way – Requirements Analysts A requirement analyst wrote the requirements. The requirements were reviewed and approved by stakeholders and given to Developers.
The New Way – Requirements Changes An-cipated Requirements are con.nuously added to the product backlog.
The Old Way – Requirements were Frozen Requirements were frozen aQer review and approval by stakeholders.
From All Up Front to Just Enough Just in Time
The New Way – User Stories Requirements are wriLen as user stories.
The Old Way – Shall Statements Requirements were wriLen in the form of “Shall” statements.
30 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Transition Requirements
The Old Way – Never Done Most teams seldom developed transi.on requirements; they focused solely on solu.on requirements.
The New Way – Drive Release Management Transi.on requirements will be key for managing release and transi.on management ac.vi.es.
The New Way – Used for Effec-ve Transi-on Transi.on requirements will become beLer understood and used for a variety of things such as
• Data Conversion • Business Con.nuity • Produc.on Turnover • Organiza.onal Change and Training • User Support • Release Management
The Old Way – Data Conversion When transi.on requirements were developed, they were mostly used for data conversion.
From Poorly Defined to Essential
The New Way – DevOps Many organiza.ons are adop.ng KanBan and other agile methods where there is a need for more frequent deployments. Transi.on requirements play a major role in facilita.ng this change and the handoffs between development and opera.ons.
The Old Way – Rigid Release Schedule In the past, organiza.ons had rigid release schedules for deployment of soQware.
31 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Requirements Validation
The Old Way – Review and Approve Large requirement documents were prepared and reviewed and approved by business stakeholders.
The New Way – Con-nuous Review and Valida-on Requirements are stored in an repository and con.nuously validated as part of the development process. Valida.on is done through ac.ve communica.on with documenta.on of design decisions.
The New Way – Requirements Validated by Feature Requirements are validated Feature by Feature instead of all at one .me. Validators only validate requirements that pertain to them. Valida.on efforts are led by the Feature Sponsor.
The Old Way – All Requirements Validated at Once A large requirement document is produced in Word and given to business stakeholders for approval. AQer significant amount of .me has passed awai.ng for necessary approvals, the requirements are given to development. The New Way – Developer, QA, and Business
Developers validate requirements for understanding and clarity. Testers validate requirements for testability. Business confirms that requirements meet business needs.
The Old Way – Business Validated Requirements Requirements were signed off by the business and simply given to developers to build the solu.on
From Long Wait Times to Continuous Review and Validation
The New Way – Minimal Viable Product Lean Startup Methods such as MVP will be used to validate concepts and assump.ons. This will result in faster product delivery and much lower development costs.
The Old Way – Review and Code Concepts, assump.ons and requirements were either validated by review and approval or placed in a backlog and coded in the case of agile.
32 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Collaboration From Non-Communicating Silos to Collaborative Team
The Old Way – Interviews Requirements Analysts mostly elicited requirements through interviews of stakeholders. The stakeholders were asked to review and approve the requirements aQer all requirements were gathered.
The New Way – Collabora-vely Maintained Requirements are developed in a collabora.ve way. Stakeholders are able to see their needs in their own words and how they map to solu.on requirements.
The Old Way – No Developer Par-cipa-on Requirements were given to the development aQer they have been approved by the business stakeholders
The New Way – Ac-ve Developer Par-cipa-on Requirements are developed in a collabora.ve way. Developers review requirements to ensure they are understood as they are being developed.
The Old Way – Minimal QA Involvement Requirements were given to QA when development received them given them liLle opportunity to fully understand them and develop meaningful tests
The New Way – Ac-ve QA Par-cipa-on QA is ac.vely involved in the requirements process ensuring at a minimum that the requirements are testable. They are oQen involved in developing test cases which become part of the requirements documenta.on.
33 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Solution Scope (Features) From Poorly Defined to Carefully Defined and Managed
The Old Way – Poorly Defined Solu.on Scope was not well defined. Many organiza.ons started with project scope and falsely believed solu.on scope was defined by the requirements.
The New Way – Carefully Defined Solu.on scope is carefully defined and managed using Features crea.ng a shared vision of what needs to be done and Impacts showing the changes that need to be made. The solu.on scope is then used to elicit requirements and manage the project.
The Old Way – Vision and Scope Statement When solu.on scope was defined, it was oQen defined in the form of a vision and scope statement. These were oQen at too high of a level to be effec.ve in managing the project.
The New Way – Impacts and Features Solu.on scope is defined as Impacts and Features. Features define the func.onality that will be developed. Impacts are used to describe the context.
The Old Way – Not Priori-zed or Managed The Scope was oQen wriLen as a textual descrip.on and might describe what was included and what was not. However, priori.za.on was seldom done as part of scoping. Requirements were seldom related formally to solu.on scope.
The New Way – Priori-zed and Managed Scope is defined in the form of Impacts and Features. Features are priori.zed based on business value and .ed to specific business objec.ves. Low value features are eliminated from the project.
34 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Business Change (Impacts) From Running Blind to Having full Transparency of Gaps and Risks
The Old Way – Seldom Done In the past, architectural impact analysis was seldom if ever done.
The New Way – An Impact Analysis is done as part of every project. Impacts are used to assess the following areas: • People (Stakeholders) • Business Processes • Technology (IT Services) • Data (Master Data, Knowledge and Analy.cs) • Governance (Business Rules)
The Old Way – Developing Technical Solu-ons The focus was purely was on providing technical solu.ons.
The New Way – Enabling Business Change Business people work with IT to iden.fy needed solu.ons and define holis.c solu.ons to solve business problems.
The Old Way – Running by the Seat of the Pants Since impact analysis were seldom performed, project managers did not have a good grasp on gaps and risks oQen discovering significant surprises late in the process
The New Way – Knowledge and Insight Project managers know the impact, capability gaps, and risks. They are able to deliver solu.ons that address the gap and beLer able to mi.gate risks.
35 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Solu-on Requirements User Stories Become the Standard for Func-onal Requirements
36 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Business Solutions
User Story Format
37 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
The Three Cs of User Stories
• Stories are tradi.onally wriLen on note cards • Cards may be annotated with es.mates, notes, etc.
Card
• Details behind the story come out during conversa.ons between stakeholders, product owner and team
Conversa.on
• Acceptance tests confirm that the story was coded correctly Confirma.on
38 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
User Story and Acceptance Criteria
As a social networker I want to upload my profile picture into Facebook So that my online friends can see what I look like.
Given the user has a valid Facebook account and a digital picture on her computer, When she uploads a picture in Facebook, Then her the picture should be visible to all her friends in her network.
Story
Acceptance Criteria
Conversa-ons
• Must be able to accept any size picture and scale to fit • Only the owner of the account can upload a picture • Must accept gif, png, pdf, and jpg
39 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Who Writes User Stories?
• Anyone can write user stories. It's the product owner's responsibility to make sure a product backlog of agile user stories exists, but that doesn’t mean that the product owner is the one who writes them. Over the course of a good agile project, you should expect to have user story examples written by each team member.
• Also, note that who writes a user story is far less important than who is involved in the discussions of it.
40 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
INVEST
Independent Can be built independently – few dependencies
Nego.able Describes func.onality to be nego.ated between the customer and development
Valuable Provides value to the business
Es-mable Has enough detail to be understandable and es.mable without being too detailed
Small They should be small -‐ should fit into a release
Testable Worded in a way that they can be tested, traced, and verified
41 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
• User stories do not work well for nonfunctional requirements. Employing user stories for NFRs is like forcing a square peg in a round pole.
• Non-functional requirements relate to qualities of the system(security, reliability, and performance) that cut across user facing features.
• The difference from functional requirements is that these qualities must be present throughout the system rather than delivered in one-shot like a user story.
• Make sure that you engage with technical stakeholders in your organization, such as architects, user experience designers, and operations teams. These people can help an agile team spot NFR that are not captured in your user stories.
User Stories do not Work Well for Nonfunc-onal Requirements
Consider nonfunc-onal requirements from the start!
42 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Start with Features Not User Stories
43 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Waste: 45% of Functionality is never used
Source: Standish Group Report at XP Conference 2002 by Jim Johnson
44 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Start with Features Not User Stories
• Generally, most requests from customers come as feature requests, not a set of well-defined user stories that are ready for development.
• It is features, not user stories that are delivered to customers and provide value to the customer.
• A feature usually contains several user stories.
• A feature can span several sprints, user stories should never span more than one sprint. When this happens, it only indicates you're missing granularity in your user stories.
• Features can be tested by the end-users, user stories are not necessarily fully testable by the end-user. In many cases testing a user-story until fully integrated with the rest of the feature might only make sense to the developer.
• Features are sometimes Epics or Themes in the Agile.
45 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Breaking Down Projects Into Small Components
• The Standish Group flatly state that that “there is no need for large projects, and that any IT project can be broken into a series of small projects.”
• It is important not to interpret breaking down projects into smaller projects as defining milestones, phases, critical paths, and activities. Delivery of concrete and usable results demarks a successful completed project.
• Small projects deliver a valuable result that is actually used to create a return on investment (ROI).
• The benefits of using this approach are quickly evident when the organization starts to receive value early in the project cycle.
Source 2013 CHAOS Manifesto Report, Standish Group
Think Big, Act Small
Breaking down a project this way requires business analysis skills as the focus is breaking down the solu.on(Product) and not defining phases and tasks.
46 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Reducing and Managing Solution Scope
• Standish Group Research shows that 20% of features are used regularly and 50% of features are hardly ever or never used. The gray area is about 30%, where features and functions get used sometimes or infrequently.
• Focusing on the 20% of the features that give you 80% of the value will maximize the investment in software development and improve overall user satisfaction.
• Reducing scope and not delivering 100% of the functionality is not only a valid strategy, but a prudent one.
Think Big, Act Small
Defining solu.on scope is in the business analysis domain. However, few business analyst do a good job in this area.
Source 2013 CHAOS Manifesto Report, Standish Group
47 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Define Solution Scope using Features
Project
Objec.ve 1 Objec.ve 2 Objec.ve 3
Feature A Feature B Feature C Feature D Feature F Feature G Feature H Feature E
Story Story Story
• The basic principle is to reduce a complex project into small, easy-‐to-‐understand units called features. This means taking one small step at a .me rather than tackling the whole project in one go.
• Each Feature should have a Business Analyst and a Sponsor from the Business. • Features should be priori.zed based on business value. • Each feature should be developed, verified and validated.
48 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Features
Link Features to Objec.ves
Describe the Business Value Provided
Priori.ze based on Value, Complexity and Effort
Assess what is required for implementa.on and user
adop.on
49 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Agile Business Requirements User Stories Do Not Define Business Needs
50 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
51 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
• Achieved a 55% ROI
• Increased production throughput by 26%
• Consolidated applications from 29 to 11
• Achieved a total savings of $14 million in 9 months
• Increased the number of sales leads by 30%
• Increased labor efficiency by 32%
• Cut procurement costs by 21%
• Reduced Inventory by 37%
Business Outcomes The success of a project should be measured based on business outcomes:
52 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Start with Objectives
Value Area Type of Objec-ve Focus Measures
User Adop-on
Reac.on What is needed to simplify user ac.vi.es?
• Usefulness • Perceived Value • Mo.va.on
Learning What do users need to become proficient with the solu.on?
• Skills • Competencies
Applica.on How can we get users to adopt the solu.on?
• Extent of Use • Frequency of Use • Elimina.on of
Workarounds
Business Outcomes
Impact What are the expected business outcomes?
• Increased Revenue • Lower Costs • Greater Throughput • Less Defects
ROI What is the expected ROI?
• Monetary Return
Based on informa1on provided by ROI Ins1tute
53 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Discovery Align to Business Objec-ves and Deliver Customer Value
Business Need or Problem and Organiza.onal Context
Business Objec.ves Business Objec.ves Business Objec.ves
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Included Features Descoped Features
People Process Technology Data Governance
Impact Analysis
• Adop.on (Artudes and Culture) • Learning (Skills and Competencies) • Applica.on (Performance) • Impact (Outcomes) • ROI {
54 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Agile Stakeholder Requirements Agile Delivery Does Not Mean Agile Business Change
55 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
USERS Users use your product. They register, login, push the buLons and move the pixels. They are the people who day in day out decide if they love it, hate it, or lie somewhere in between. Different users use different aspects of your product, so they fall into different classes. For example, you might find sales reps, sales mangers, marke.ng managers, and administrators all as users in a CRM system.
CUSTOMERS Customers buy your product. They find it. Evaluate it. Decide to purchase it, and ul.mately pay for it. No customers means no business so they maLer a lot. To understand your customers, you have to understand who is making the decision to buy your product, and it’s oQen a group, which in common parlance is called a decision making unit (DMU).
Users vs. Customers
56 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Customer and User Discovery
• The goal of Customer Discovery is to find a market for you product and to build a product that prospective customers will buy. Customer discovery techniques include: o Developing Customer Personas o Needs exploration with the DMU o Product validation with the DMU o Pricing analysis and testing o Marketing sizing
• The goal of User Discovery is to create a product that delights users. Products that users love get far more traction than ones they don’t like. User discovery techniques include: o Developing User Personas o Contextual interviews o Walking through a prototype o A/B testing on a site o Scrappy usability tests o User diaries o Analyzing usage data
57 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Focus on the Job
Virtually all products and services are acquired to help get a job done. In the outcome-‐driven paradigm the focus is not on the customer, it is on the job: the job is the unit of analysis. When companies focus on helping the customer get a job done faster, more conveniently, and less expensively than before, they are more likely to create products and services that the customer wants. Only aFer a company chooses to focus on the job, not the customer, are they capable of reliably crea1ng customer value.
58 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Discover What is Required for User Adoption
User Personas. Understand what users activities are.
Prototypes. Document characteristics and expectations of different user types.
Scenarios. Design and validate the user experience.
59 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
User Personas and Roles
Role Persona What do I want to Do? How will it help me?
Brandon Equity Trader
• 27 • Single • Marathon runner • Works hard and par.es hard
Wants to see current market condi.ons
• Buy and sell equi.es • Real .me decisions • Raid search tools
Judy Por]olio Manager
• 35 • Married • Loves yoga, fine dining and wine
• PHD in Finance
Wants to maintain an effec.ve por]olio
• Perform scenario modeling
• Maintain diverse por]olios
Craig IT Support
• 25 • The phone is part of his life • Wants to impress • Loves coffee
Understand users’ problems and solve them
• Take control of users applica.ons
• Review and mine audit logs
Janet Rela.onship Manager
• 53 • Loves social networking • Married, 3 children • Poli.cally powerful
Cross sell products to customers
• Track contacts made with customers
• More flexible repor.ng
60 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Personas and Scenarios are Used in User Stories
61 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Increase Up-‐Sells on Sales Orders by 20% by January 2014.
• Build up-‐sell business rules and data rela.onships considering customer profile and products being ordered.
• Add up-‐sell sugges.ons to Web-‐based order processing system. • Add up-‐sell sugges.ons to Call-‐Center order processing system. • Produce reports and queries to measure performance
Objec-ve
Features
Personas • On-‐line Customer • Call Center Sales Agent • Sales Data Manager • Director of Sales
Systems • Web Order Entry System • Call Center Order Processing • Product Master Data • Upsell Business Rules
Stories • As the Director of Sales, I want to know the amount of sales that were generated from up-‐sell recommenda.ons provided to the customer so I can op.mize the data to produce more up-‐sells.
• As the Director of Sales, I want to know the percentage of sales orders that had up-‐sell items so that I can op.mize sales opportuni.es
Putting it All Together
62 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Summary • Agile adoption will continue to grow and user stories will be the standard format for
solution requirements. There will be many problems as agile begins to scale specifically with coordinating agile delivery with business change, cultural change, Devops, and grooming managing ever growing product backlogs.
• Requirements will be developed collaboratively as user stories. The focus for project mangers and business analyst will be on defining and validating Features and enabling business change. Traditional requirements analysts focused on writing solution requirements will need to develop new skills or retire.
• Paper requirement documents will vanish. Requirements and related data will be maintained electronically in backlogs. Review and approval will be done electronically and continuously.
• Businesses that have developed a strong Discovery capability will have a significant competitive advantage over those organizations that have not.
• New tools such as Enfocus Requirements Suite™ will emerge as key for managing discovery and business change.
63 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
You need Enfocus Requirements Suite to Succeed in Agile Discovery.
We help you deliver be_er business outcomes, more quickly and at less cost.
64 © Copyright 2013 Enfocus Solutions Inc. All Rights Reserved.
Thank You Learn how to deliver more business value on your projects Please request a consulta.on.
www.enfocussolu.ons.com