Stop killing requirements

STOP KILLING REQUIREMENTSHOW TO MAKE YOUR PROJECT EFFECTIVE YET AGILE

@MELISSAGREENWS | #STOPKILLINGREQ!

MELISSA GREEN - [email protected]

#stopkillingreq !

MELISSA GREEN, ABOUT ME• CEO, Wirestream

• Business Analyst background

• Gamer, movie lover, kitchen dweller, husky owner, mom & wife.

https://www.youtube.com/watch?v=BKorP55Aqvg

#stopkillingreq !

WHAT ARE WE HERE TO TALK ABOUT?• What are requirements and why are they important?

• How do I get requirements into an agile-based project?

• What tools are out there to manage my requirements in an agile-development path?

• How can my requirements help/impede my off-shore team?

#stopkillingreq !

WHAT ARE REQUIREMENTS

#stopkillingreq !

SO THEN WHY DO THEY GET “KILLED” (AKA DE-PRIORITIZED) IN AGILEWorking software over comprehensive documentation.

• Misunderstand this to mean there is no need for requirements at all.

#stopkillingreq !

SO THEN WHY DO THEY GET “KILLED” (AKA DE-PRIORITIZED) IN AGILEWaterfall team lead who doesn’t understand agile.

• Want waterfall based documentation that inhibits an agile-process from working as it should; therefore requirements that may exist are disregarded or interfere with work.

#stopkillingreq !

WHY ARE REQUIREMENTS IMPORTANT• According to new research, success in 68% of

technology projects is "improbable." Poor requirements analysis causes many of these failures, meaning projects are doomed right from the start. ~ Tech Republic

Companies with poor business analysis capability will have three times as many project failures as successes.

68% of companies are more likely to have a marginal project or outright failure than a success due to the way they approach business analysis. In fact, 50% of this group's projects were "runaways" which had any 2 of: taking over 180% of target time to deliver; consuming in excess of 160% of estimated budget; or delivering under 70% of the target required functionality.

Companies pay a premium of as much as 60% on time and budget when they use poor requirements practices on their projects.

Over 41% of the IT development budget for software, staff and external professional services will be consumed by poor requirements at the average company using average analysts versus the optimal organization.

Companies with poor business analysis The vast majority of projects surveyed did not utilize sufficient business analysis skill to consistently bring projects in on time and budget. The level of competency required is higher than that employed within projects for 70% of the companies surveyed, will have three times as many project failures as successes.

#stopkillingreq !

BUSINESS VS FUNCTIONAL

• Business requirements are the critical activities of an enterprise that must be performed to meet the organizational objective(s) while remaining solution independent.

• A business requirements document (BRD) details the business solution for a project including the documentation of customer needs and expectations.

Business - What / Idea• In software engineering (and systems

engineering), a functional requirement defines a function of a system and its components.

• A function is described as a set of inputs, the behavior, and outputs (see also software).

Functional - How / Actual

Based on a user's location (IP detection) customer service or company contact information could be

provided to contact the company easier than navigating to other contact points.

Based upon the user’s location via IP-Detect a phone number will display in the upper right of the

page; this number will be ever-present. Phone number will be enabled so that at mobile

resolutions the user may touch to call.

#stopkillingreq !

HOW IS A REQUIREMENT CONVEYED IN AN AGILE-BASED PROCESS

• A user story is a tool used in Agile software development to capture a description of a software feature from an end-user perspective.

• The user story describes the type of user, what they want and why. A user story helps to create a simplified description of a requirement.

As a website visitor I want a phone number displayed based on my location so that I

can efficiently contact the company.

#stopkillingreq !

WHAT IS THE DIFFERENCE AND WHY DOES IT MATTER






Fundamentally - a user story is NOT a functional requirement, it is a guide (idea) only.

#stopkillingreq !

WHY IS THIS AN ISSUEAgile user-stories aren’t clear enough to deduce functionality.

• Developers tend to spend time building something that the business does not expect because it was not fully defined.

• Not enough time was dedicated to the requirements (as this conflicts with the first challenge) and the business doesn’t understand what they’re reviewing/testing/approving.

How can requirements be written/managed in an agile based project?

#stopkillingreq !

WHERE IS THE TIME FOR REQUIREMENTSSprint 0: Avoid allocating months ahead of actual development by just working “a (1) sprint ahead” - write your requirements for the next sprint, in the current sprint.

Three Week Sprints: Longer sprints not only allow for more velocity, more development hours and the ability to complete more features but allows for the introduction of time to review and analyze requirements by developers.

Dev Review/Accept: provides a day (or 1/2 day) for the development team to review requirements, understand them and accept them. Builds ACCOUNTABILITY.

#stopkillingreq !

WHAT DOES A THREE WEEK SPRINT LOOK LIKE

Friday

Backlog GroomingSprint Planning

1

Monday

Dev ReviewDev EstimationKick Off

1

Development CycleTuesday – Thursday

12/13-12/22

Friday

Sprint ReviewSprint Close

3

2

Daily Stand Ups

#stopkillingreq !

WHAT ARE ROLES I SHOULD ENSURE ARE A PART OF MY PROJECT

Product Owner ScrumMaster Lead Developer Business OwnerOwns the product

roadmap and determines what

features are introduced into the product when.

Responsible for working with the business to

define and keep point on objectives.

Manages the agile process and key tasks to

keep the process flowing (stand-ups,

demonstrations, retrospectives, etc.)

CAN AND SHOULD BE OWNER OF

REQUIREMENTS.

Supports driving the development team in

making the right decisions based on user stories and acceptance criteria. Works with the

ScrumMaster and Product Owner for

clarifications.

Someone inside the business who is owner

of the product. This person is responsible at an accounting level for the success or failure of the product as a whole.

What do requirements in an agile-based process

look like?

#stopkillingreq !

KEYS TO BUILDING REQUIREMENTS BUT STILL BEING AGILE

User Story / Task

Epic

#stopkillingreq !

WHAT SHOULD AN AGILE USER STORY LOOK LIKE

As [a user] I need/want [some goal] So that [some reason]

Requirements: Key elements that must exist for the business to approve

{THIS IS WHAT IS USUALLY MISSING!}

Epic: a large theme that typically will cross sprints; will contain smaller user stories to execute this objective.

User Story/Task: a statement declaring the need of a user for a feature with defined acceptance criteria.

#stopkillingreq !

MY PROJECT HAS AGILE USER STORIES - HOW CAN I BE AT RISKInterpretation is subjective (and not all developers are good at interpreting the need).






What?

Where?

How?

#stopkillingreq !

MY PROJECT HAS AGILE USER STORIES - HOW CAN I BE AT RISK

As a website visitor I need the ability to subscribe to a newsletter so that I can stay up to date with the company’s product releases.

What: answered in the above user story.

Where: Where on the site can the user subscribe? from what pages? Where is this data going?

How: how is this going to work for different languages?

Without these questions answered it is likely this feature will be built in such a way that the business will fail it at some level.

#stopkillingreq !

WHAT DOES A BAD USER STORY LOOK LIKEAs [a user] I need/want [some goal] So that [some reason]


{THIS IS WHAT IS USUALLY MISSING!}

As a user I want a phone number to call so that I can

reach customer service.

Phone number displays on site.

As a user I want a phone number to call.

Missing: Reason (so that)

#stopkillingreq !

WHAT DOES A BETTER USER STORY LOOK LIKEAs [a user] I need/want [some goal] So that [some reason]


As a 65+ website user I want to easily see/find a phone number

to call so that I can reach customer service.

Phone number should display ever-present on the upper right of the screen

Phone number to display is 888-123-4567

On mobile resolutions phone number should have touch to call enabled

Underneath phone number customer service hours, with time zone, should

display

Font size must be 18+ points

Now that I can describe the requirements I need how can I

convince my organization to create them?

#stopkillingreq !

HOW CAN I INCORPORATE REQUIREMENTS GATHERING INTO MY PROJECT

• Define epics and user stories at the start of the project or at the start of agile implementation. The product owner and ScrumMaster should be responsible for this.

• Incorporate waterfall aspects into the agile process but don’t lose the core of agile; options include:

• Prior to each sprint planning session allow the ScrumMaster to fully define acceptance criteria for the stories. Get approval from the business if required and possible.

• Plan for time at the beginning of each sprint to gather the requirements for a user story that might exist.

#stopkillingreq !


• Provide time at the beginning of each sprint for the developers to review the user stories on the board of each sprint and get clarification up front before beginning the development cycle.

• If a user story cannot be defined with appropriate acceptance criteria exclude it from the sprint. The product owner and business owner must address the lack of acceptance criteria and its impact to the product objectives.

#stopkillingreq !


• Most importantly - understand that user stories don’t always fit.

• In some cases the business may understand tasks better “build this report” or “create a contact us form” - allow these things to happen if it means getting permission to write the requirements (especially from the waterfall guy).

You’ve convinced them you need requirements, now

what do you do with them?

#stopkillingreq !

MOVING USER STORIES THROUGH THE “BOARD”

#stopkillingreq !

USER STORIES BY STICKY NOTE

Positive: • Gives the business owner and

product owner (and team) visibility into the sprint’s velocity.

Negatives: • Does not provide solid

requirements for the actual user story (e.g. acceptance criteria).

#stopkillingreq !

INTRODUCTION OF USER STORY CARD

The story card allows a developer to pick up the requirements associated to a user story. These can be developed throughout the project and allow for some measurement of success.

#stopkillingreq !

INTRODUCTION OF USER STORY CARD

Corresponding Post It

Reference Number

Ticket Summarization

Developer

Priority

#stopkillingreq !

ONLINE/DOCUMENT BASED “BOARD” EXCEL OR GOOGLE DOC

#stopkillingreq !

ELECTRONIC VERSION OF THE BOARD KANBAN FLOW

Online Visibility Acceptance Criteria = Sub Tasks

#stopkillingreq !

ELECTRONIC VERSION OF THE BOARD JIRA

#stopkillingreq !

HOW DO WE STRUCTURE A REQUIREMENT IN AGILE

Exceptions List Report

Mobile App

Iteration 1

StoryAs a user I need a report that lists all system exceptions so that I may address issues as quickly as possible.

Requirements• The following data must display:

• Page • Action • Error Code • User Name • Date/Time in UTC

• User will have the ability to sort based on date/time, page and error code.

• Default state will sort all exceptions by date/time.

• Filters will exist to allow a user to show only results based on a page or error code. User may only set 1 level of filtering.

#stopkillingreq !



Mobile App

Iteration 1

Acceptance Criteria• User must be able to go to the

exception list report. • User must be able to sort results

by date/time, page and error code.

• User must be able to filter results to show based on a single page selection. Results list should show all error codes that apply to the page selected.

• User must have the ability to reset the list view after filtering.

• User must be able to filter results to show based on a single error code selection. Results list should show all pages that apply to the error code selected.

• Etc.

#stopkillingreq !



Mobile App

Iteration 1

DiscussionLeverage this space for developer Q&A on the requirements.

How do I identify the requirements I now have aren’t right for the job?

#stopkillingreq !

INDICATORS THAT THE RIGHT REQUIREMENTS DON’T EXIST

Good: shows continuous progress and that work is being completed and is passing.

Bad: shows stagnant results indicating team is likely spinning or is impeded in some way.

#stopkillingreq !

INDICATORS THAT THE RIGHT REQUIREMENTS DON’T EXIST

Other indicators: • Stories (or tasks) keep reappearing sprint to sprint -

means requirements not clear or task too big • During demonstrations the business keeps referring to

things “they didn’t expect to work that way” • Stories (or tasks) get handed off from developer to

developer throughout a sprint (in an uncoordinated fashion)

• Impediments remain more than 24 hours on an item • Anything but a happy path fails in testing

#stopkillingreq !

WHAT IF MY COMPANY DOESN’T WANT TO SUPPORT THE REQUIREMENTS GATHERING PROCESS/NEED

• Hit them with the facts - there is plenty of data to convince the business requirements are critical.

• Pull a previous project from your company’s history and evaluate time + budget against requirements available.

• Let a sprint fail.

How do good requirements help off-

shore/distributed teams?

#stopkillingreq !

WHAT DOES A THREE WEEK SPRINT LOOK LIKE WITH TIMEZONES

Thursday 8/18/2016

Kansas CitySprint Planning11a – 1p (KC)9:30p – 11:30p (IN)

1

Friday8/19/2016

BangaloreSprint Estimating11:30p – 3:30a (KC)10a – 2p (IN)

1

Friday8/19/2016

Kansas CitySprint Finalization9a – 10a (KC)7:30p– 8:30p (IN)

1

Development CycleMonday 8/22/2016–

Wednesday 9/7/2016

Thursday9/8/2016

Kansas CityDemonstration7a – 9a (KC)5:30p – 7:30p (IN)

3

2

Thursday9/8/2016

Kansas CityRetrospective9am – 10:30am (KC)7:30p– 9pm (IN)

4

Thursday9/8/2016

BangaloreRetrospective8p – 9p (KC)10:30a-11:30a (IN)

4

Daily Stand Ups:(1) 8a (KC), 6:30p (IN)(2) 9p (KC), 7:30a (IN)

Wirestream Engagement Manager Leads / Relays to

Client Team via Scrum of Scrums

#stopkillingreq !

WHY IS LEVEL OF DETAIL IMPORTANTRequirements:

1 Save Action - upon touch: ◦ If the video is a baseline video user shall be notified that their baseline video may not be changed

and prompted to confirm they wish to save the video. ▪ If user cancels this message the notification will be cleared from the screen and user will be

left on the Video Capture screen. ▪ If user confirms message the baseline video will be saved and user will be returned to the

Video Diary Landing Page ◦ If the video is a progress video the video shall be saved and replace the previous progress video

(if one exists). 2 The video will store locally until it is uploaded into the servers; all uploading into the database will

happen in the background - the user will not be made aware. 3 The user will be immediately returned to the Video Diary landing page and a still (or first frame) from

the video captured will display in the container the video is assigned to and the Progress Recorded date will be updated to date video was captured.

4 All videos shall save against: Pet Parent / Pet / Assessment Question.

#stopkillingreq !

WHY IS LEVEL OF DETAIL IMPORTANTRequirements:

• Video will store on user’s local device at all times.• As soon as a connection is available the video will upload to the server and

delete from the user’s local device.• If a user is not connected the local video will play back. • Once the user’s video has uploaded to the server and is no longer

available locally the user will see a message displayed “Videos available with wifi or carrier internet connection.”

#stopkillingreq !

SUMMARY• Requirements define how things should work and set

expectations to create efficiency and reduce error.

• Incorporating GOOD requirements into an agile process will ensure the possibility of success.

• Make sure, no matter the level of agile, that a tool is used to navigate the process and share the requirements.

• Use facts to convince naysayers that requirements are golden (and valuable).

Software

Stop killing requirements