1.
Driving Better Requirements
Through DevOps

2.
Cecile Hurley – Customer Success Manager
Welcome to the Webinar
Driving better requirements – Through DevOps
churley@navvia.com Twitter: @cecile_hurley

3.
Driving better requirements – Through DevOps
Housekeeping
Let’s keep this interactive!
• Use the control panel to ask questions
• Can you see & hear us?
• enter your name & city to confirm
Type Your Questions Here

4.
DevOps – Evolution not revolution
Software & Services
to design & document IT and Business Processes

5.
Driving better requirements – Through DevOps
Recognized by… Used by…

6.
Driving better requirements – Through DevOps
What is Navvia
Navvia is a Powerful and easy-to-use tool to design
& document processes & capture requirements
RACI
Auto generate and synchronize over 17
different process artifacts
Process Guides
Technical Requirements
And more…
Create

7.
CEO and Co-founder
David Mainville
Driving better requirements – Through DevOps
dmainville@navvia.com @mainville

8.
Driving better requirements – Through DevOps
“The failure rate of IT projects is appalling…
… despite more than 50 years of history and countless
methodologies, advice and books, projects keep failing...
irrespective of the methodology — waterfall or agile”
Gartner – October 2014
Problem Statement

9.
Driving better requirements – Through DevOps
And the type of project doesn’t matter…

10.
Driving better requirements – Through DevOps
So why do we keep failing? … thoughts?

11.
Driving better requirements – Through DevOps
Some common reasons for failure
• Automating overly complex business processes
• Too much project bureaucracy / too little planning
• Lack of accountability & governance
• Lift & Shift of the old system
• The fallacy of “out of the box”
• Scope creep & and “finish at any cost” attitude
• Brooks Law: When a product is crashing, burning and delayed, throwing more people at it only
makes it crash harder, burn faster, and be more delayed. – Fred Brooks: The Mythical Man-
Month
Why do we keep failing?

12.
Driving better requirements – Through DevOps
The #1 Reason Projects Fail - Poor Requirements
Why do we keep failing?
There is a disconnect between what the
Business wants & needs and what is
delivered as a solution.

13.
Driving better requirements – Through DevOps
Is there a better path to business value?
DevOps

14.
Driving better requirements – Through DevOps
Defining DevOps
Source: DevOps ReferenceArchitecture, Source: IBM
Steer
Develop
/ Test
Deploy
Operate
DevOps
Continuous Business
Planning
Collaborative
Development
Continuous
Testing
Continuous Release
& Deployment
Continuous
Monitoring
Continuous Customer
Feedback &
Optimization
Continuous
Feedback

15.
Driving better requirements – Through DevOps
Defining DevOps
• Steer
• Document business objectives desired in business terms
• Identify all the roles/personas involved with the software
• Understand the broad scope of the project
• Develop
• Create stories that describe the business objectives into role based features
• Translate the stories into technical terms developers can work with
• Group requirements into short sprints / validateresults with the business
• Create test scripts based on stories
• Deploy / Operate
• Validate the new features and obtain customer feedback

16.
Driving better requirements – Through DevOps
Start with the business requirement

17.
Driving better requirements – Through DevOps
But don’t go down the rabbit hole

18.
Driving better requirements – Through DevOps
Understand the roles / personas
• Identify all the potential users of the system
• Group the users into specific roles / personas
• Fictitious users based on your knowledge of real users
• Personalize the personas – as real as possible
• One time or casual customer vs. user
• Ensure all your personas are considered when
developing requirements
• You are not at end-of-job until all personas are addressed
• Capture role / persona requirements in ”stories”
• Roles / personas, and associated stories, are critical for
testing

19.
Driving better requirements – Through DevOps
As a <role>, I want <feature>, so that <benefit>.
• Here are a couple of examples:
• As an unauthenticated user, I want to see the login link in the upper right hand corner of each
page, so I don’t need to navigateback to the homepage or some account page to login.
• As a sales associate, I want to be able to pull up my current activeleads, deals and tasks on my
iPhone, so that I can still follow up with clients and update deals status while traveling.
• Don’t forget the benefit – it addresses the business outcome
Credit: Dan North and Chris Stevenson’s story framework.
Build user stories

20.
Driving better requirements – Through DevOps
Tying it all together
Business Outcomes
Roles / Personas
Role based Stories
(epics)
Detailed Requirements
(sprints)
Streamline Ordering
Process
Online Shopper Agent Supervisor
The Online Shopper purchases items with a
single click so they can save time & effort
The detailed technical requirements needed to
fulfill the story e.g. Credit card on file…
Manager
Drive more sales /
recommend items
Fewer abandoned
carts
Role based
story 2
Role based
story 3
Detailed
requirement
Detailed
requirement

21.
Driving better requirements – Through DevOps
IT projects fail regardless of the methodology
It’s not the methodology – but how you practice it

22.
Driving better requirements – Through DevOps
Practicing DevOps
Source: DevOps ReferenceArchitecture, Source: IBM
Steer
Develop
/ Test
Deploy
Operate
DevOps
Continuous Business
Planning
Collaborative
Development
Continuous
Testing
Continuous Release
& Deployment
Continuous
Monitoring
Continuous Customer
Feedback &
Optimization
Continuous
Feedback

23.
Driving better requirements – Through DevOps
Takeaways
• Focus on business outcomes / not technical specifications
• You don’t need to capture all requirements at the get-go
• Have a high-level plan and let it evolve collaboratively
• Collaborate and Communicate
• A discussion is worth more than a document
• Constantly validaterequirements (show and tells)
• Get the business involved with the developers throughout
• Identify your roles / personas
• Build outcome based (benefits) stories
• Which in turn lead to technical specifications
• Build a realistic plan that addresses governance and accountability

24.
Driving better requirements – Through DevOps
Product Demo

25.
Navvia Process Designer
Thank-you
David Mainville dmainville@navvia.com Twitter: @Mainville