Esri Best Practices: How to run an AGILE GIS project · project •Limited capacity, resources, and environment •Frequent turnover on project team •Medium or large size, mid to

Esri Best Practices: How to Run An AGILE GIS ProjectJennifer Prather and Betsy Leis

Who’s familiar with Agile?

How to Start…

Discuss similarindustries

Assessworkflows

Prioritizeworkflows

Create a plan

Conduct kickoff meeting

56

Choose a life cycle

Launching your Location Platform Guide:www.esri.com/LaunchGuide

5

http://www.esri.com/%7E/media/files/pdfs/library/pdfs/location-guidehttp://www.esri.com/LaunchGuide

The Agile Approach

Agile Manifesto

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

AGILE

User Story: A user story is a few sentences in the most basic of terms that outline the desired outcomes a goal written from the user’s perspective. Provides just enough information so that the developers can produce a reasonable estimate of the effort to implement it.

Sprint/Iteration: In the Scrum method of Agile software development, work is confined to a regular, repeatable work cycle, known as a sprint or iteration. Scrum sprints used to be 30 days long, but today we advise two-week sprints.

Epic: An Epic can be defined as a feature, which will take one or more sprints to complete. By observation 5-10 user stories comprise of one Epic in agile methodology.

Agile: Agile development is an alternative to traditional project management where emphasis is placed on empowering people to collaborate and make team decisions in addition to continuous planning, continuous testing and continuous integration.

Scope, Technology, Contract

When would you use Agile?

Waterfall

• Clear requirements• Fixed deliverables• Single application

Staged Delivery

• Several applications• Prototypes expected

Agile

• Flexible scope, deliverables

• One or several applications

Capacity, Capabilities,Environment

Size,Duration

• Small size, short duration project

• Limited capacity, resources, and environment

• Frequent turnover on project team

• Medium or large size, mid to long duration

• Capacity, resources, and environment to support multiple releases

• Customer EXPECTS collaboration

• Stable, experienced project team

• Any size or duration project

Proposing Agile

Big Picture

System Architecture

DatabaseDesign Widget 1 Widget 2

ApplicationHardening

21

Story Points

34 34 45 21

EpicsStory point is a arbitrary measure used by Scrum

teams. This is used to measure the effort required to implement a story. In simple terms its a number that tells the team how hard the story is. Hard could be related to complexity, Unknowns and effort. In most cases a story point range is1,2,3,5,8,13,21,34,45

21 34 34 45 21

168 272 272 360 168

Story Points

Hours

Activity ScrumMaster

Product Owner

Developer Analyst System Admin

Total

System Architecture 168

Geodatabase Design 272

Widget 1 272

Widget 2 360

Application Hardening 168

Pricing Sheet

16 16 0 16 120

24 24 0 184 40

24 24 176 48 0

20 20 240 80 0

40 16 84 24 4

Work Breakdown Structure

System Architecture

DatabaseDesign Widget 1 Widget 2

ApplicationHardening

Project

1.1 User Story

1.2 User Story

2.1 User Story

2.2 User Story

2.3 User Story

3.1 User Story

3.2 User Story

3.3 User Story

3.4 User Story

4.1 User Story

4.2 User Story

4.3 User Story

4.4 User Story

4.5 User Story

5.1 User Story

5.2 User Story

Managing Agile

Scrum Sprint Cycle

Product Backlog Sprint Planning Sprint Backlog

Potentially ShippableProduct Increment

2 - 4 WeekSprint

ProductOwner

ScrumMaster

The team

Retrospective

Daily Scrum

Stakeholders

KanBan Approach (Still Agile, just not Scrum)

• No defined iterations• No defined roles• Direct communication with customer

• Limit your work-in-progress• Visualize your work• Ever-changing backlog with on-the-fly prioritization

Let’s talk about people

• People have personalities

• Personalities can be tricky

Collecting Requirements

User stories facilitate a conversation with the team and with the users…

ProductOwner

ScrumMaster

The teamStakeholders

ndependent. Reduced dependencies = easier to planegotiable. Details added via collaborationaluable. Provides value to the customerstimate-able. Too big or too vague = not estimate-ablemall. Can be done in less than a week estable. Good acceptance criteria

A good user story uses the “INVEST” model:

INVEST

Build for Value

Standish Group Study Reported at XP2002 by Jim Johnson, Chairman

Requirements evolve over time

Chart1

Always

Often

Sometimes

Rarely

Never

Used

0.07

0.13

0.16

0.19

0.45

Sheet1

Used

Always7%

Often13%

Sometimes16%

Rarely19%

Never45%

To resize chart data range, drag lower right corner of range.

Example – Enterprise Geocoding ServicesDecomposing work into manageable pieces

As an employee I need locators to be built on my Agency

Data.

As an employee I need an authoritative geocoding service.

As an employee I need a cascading set

of locators.

As a business owner I need a geocoding service available to

3rd party applications.

Provide Enterprise Geocoding Services

Feature level Epic

User Stories

Product Backlog

Wish List

Sprint Backlog

4h

Sprint Backlog

3 days8h

2 days1h

2h

4h 8h

How do we know when we are done?Confirmation…the acceptance test

How do we know when we are done?Confirmation…the acceptance test

• Given I have enabled offline access on my map

• When I click on the map to create a feature

• Then the feature will be stored locally until I sync with connectivity.

How do we know when we are done?Couple of things to note…

• Define acceptance just in time…don’t waste too much time• Part of the conversation process• Acceptance consistency (given…when…expect) is helpful, but not necessary

Definition of Done

Examples of practices that might be included in the definition of “done:”

• Acceptance criteria met• Code is reviewed by another development team member• Test cases are written• Unit tests and UI automation tasks are written• Feature is tested for accessibility

We don’t do strict…

treehousehttp://blog.teamtreehouse.com/when-is-a-user-story-done-acceptance-criteria-definition-done

http://blog.teamtreehouse.com/when-is-a-user-story-done-acceptance-criteria-definition-done

Example – Enterprise Geocoding ServicesDecomposing work into manageable pieces

Provide Single Line capabilities

Logic adheres to the following order building point, street centerline,

zip code

As an employee I need locators to be built on my Agency

Data.

Integrate reference data for building and

street centerlines

As an employee I need an authoritative geocoding service.

API documentation

As an employee I need a cascading set

of locators.

As a business owner I need a geocoding service available to

3rd party applications.

99.99% SLA

REST service

Provide Enterprise Geocoding Services

Feature level Epic

User Stories

Acceptance Criteria

Provide Reverse capabilities

Provide Batch capabilities

• Change control of requirements• Capturing notes/conversations

What if my customer changes their mind?

Prioritized Changes

(Unapproved)

Prioritized Changes

(Approved)

Prioritized Product Backlog

Updated Prioritized Product Backlog

Change 1

Change 2

Change 3

Change 2

User Story 1

User Story 2

User Story 3

User Story 1

User Story 2

User Story 3

Change 2

Watch out for the ‘Gotchas’Things to avoid

• Avoid long lists of acceptance criteria on a single user story

• Prepare for conflicting requirements • Avoid requirements that are ambiguous• Avoid requirements that describe HOW• Requirements must have a “reason”• Avoid moving forward on development until after the

customer has reviewed the design• Don’t forget to prioritize

How to Esri Manage this Agile Cycle?

Using Agile in a Professional Services ProjectM

etho

d

Waterfall

Agile

Time

Met

hod

Waterfall

Agile

Time

Using Agile in a Consulting Project

Met

hod

Waterfall

Agile

Time

Final Release

Using Agile in a Consulting Project

Managing Resources

Your Project

Plan A Plan BSprint

50%

75%100%75%

50%100%

100%50%

Plan ZSprint

50%

75%100%75%

50%100%

100%50%

50%

50%

50%

50%50%

Keys to Successful Projects!

Communication

Utilize Available Tools…

Trusted Partnerships

Transparency

Waffle.io

Microsoft Team Foundation Server (TFS)

Requirement Management ToolsLicensed and Open Source

JIRA

Compare

https://waffle.io/http://project-management.zone/system/jira,pivotal-tracker,team-foundation-server,trello

Tool to assist in Release PlanningRealTimeBoard

Using Trello

Using GitHub

Using TFS

Making a Decision

Project Considerations Trello GitHub TFS

Requirements are Proprietary

Mobile App

Easy to setup

Estimation tools

Scheduling tools

Automated Burndown chart

Easily integrated with Visual Studio for Code Repository

Capacity Planning

Exports to MPP and Excel

38

There is a lot of info out there to help

http://assets.cdnma.com/13314/assets/Website Downloads/2016-Seilevel-RequirementsTool-Evauation-Report-FINAL.pdf

http://project-management.zone/system/jira,pivotal-tracker,team-foundation-server,trello

http://assets.cdnma.com/13314/assets/Website%20Downloads/2016-Seilevel-RequirementsTool-Evauation-Report-FINAL.pdfhttps://project-management.zone/system/jira,pivotal-tracker,team-foundation-server,trellohttp://assets.cdnma.com/13314/assets/Website%20Downloads/2016-Seilevel-RequirementsTool-Evauation-Report-FINAL.pdfhttp://project-management.zone/system/jira,pivotal-tracker,team-foundation-server,trello

Last year, Business Analyst Learnings published an article comparing 3 free requirements management tools. Go check them out!

Free, open source fans?

https://businessanalystlearnings.com/technology-matters/2017/7/4/a-list-of-free-requirements-management-rm-software

https://businessanalystlearnings.com/technology-matters/2017/7/4/a-list-of-free-requirements-management-rm-software

Requirements and StakeholdersTHE most important part of a project

• Solid requirements gathering leads to successful projects• Consider solution, COTS capabilities before collecting additional

requirements• Involve the right people in the process• Pick a methodology that fits your project• Focus on the level of detail that is appropriate• Important to prioritize and allocate• Invest plenty of time to secure customer approval

Case Studies



3 DaySprint

ProductOwner

ScrumMaster

The team

Retrospective

Daily Scrum

Stakeholders

Lead developerCustomer’s PM

Customer’s PM

Dev team of 2UI/UX as neededProject Manager

Small ScaleContract Type $$ Value

T&M $110K

Case Study – Small Scale• Why Agile?

• Requirements (User Stories) are not clearly defined at the time of contract award.

• Key Challenges / Lessons Learned- Stakeholders (customer) was an active participant with respects to the grooming

of the product backlog including prioritization.- Standard sprints do not work with the customer’s schedule as the work comes in

waves rather than a steady pace.- Finding resources to staff a project like this can be difficult since the work is not

planned out well in advance.



1 WeekSprint

ProductOwner

ScrumMaster

The team

Retrospective

Daily Scrum

Stakeholders

Lead developerAnalyst

Customer’s PMInternal PM

12 developers2 testers1 PMFluctuates as needed

Case Study – Medium ScaleContract Type $$ Value

T&M $4M

Case Study – Medium Scale• Why Agile?

• Customer was familiar with Agile and believed iterations was the best method to get to realize their end goal

• Key Challenges / Lessons Learned- Stakeholders (customer) was an active participant with respects to the grooming

of the product backlog and sprint planning events.- Team consisted of contractors from multiple companies who were all using their

own version of Scrum- Utilization of multiple contractors created dependencies that had to be accounted

for in Sprint Planning.- Hours were used for estimates to avoid an inconsistent Points experience- Monthly iterations, then bi-weekly, then weekly, then back to bi-weekly in order to

get the right amount of feedback

Product Backlog

Sprint Planning

Sprint Backlog


2 WeekSprint

Release Manager Scrum of ScrumMaster

The team

Retrospective

Daily Scrum

Stakeholders

Lead developerAnalyst

Customer’s PMProject Manager

Daily Scrum

Daily Scrum

Sprint Planning

The team

Sprint Planning

The team

ScrumMaster

ProductOwner

ScrumMaster

ProductOwner

ScrumMaster

ProductOwner

Sprint Backlog

Sprint Backlog

Scrum of Scrums

Analyst Analyst AnalystDeveloper Developer Developer

~7 developers1 tester



Case Study - Large Scale Contract Type $$ ValueFFP-LOE $9M

Case Study – Large Scale• Why Agile?

- Project was contractually required to follow the SAFe Agile Methodology.- Requirements were vague and customer recognized the benefit in iterative

development to achieve the best results.

• Key Challenges / Lessons Learned- Deployment into the customer’s footprint occurs at the end of the Release. - Large project team to manage.- Each Scrum Team was responsible for individual features.- Dependencies existed between scrum teams.- Stakeholders (customers) were only present during Stakeholder Reviews and

were not active participants during the release planning events.- Disconnected environment meant that the customer could not test the features

until the end of a release.- Bi-weekly demonstrations to “sell off” features and to show progress.

Questions

Print Your Certificate of AttendancePrint Stations Located at L Street Bridge

Tuesday Wednesday12:30 pm – 6:30 pm GIS Solutions Expo Hall D

5:15 pm – 6:30 pm GIS Solutions Expo SocialHall D

10:45 am – 5:15 pm GIS Solutions Expo Hall D

6:30 pm – 9:00 pm Networking ReceptionNational Building Museum

Please Take Our Survey on the AppDownload the Esri Events app and find your event

Select the session you attended

Scroll down to find the feedback section

Complete answersand select “Submit”

Esri Best Practices: How to Run An AGILE GIS ProjectWho’s familiar with Agile?How to Start…The Agile ApproachAgile ManifestoSlide Number 6When would you use Agile?Proposing AgileSlide Number 9Slide Number 10Slide Number 11Slide Number 12Managing AgileScrum Sprint CycleKanBan Approach (Still Agile, just not Scrum)Let’s talk about peopleCollecting RequirementsSlide Number 18A good user story uses the “INVEST” model:Build for ValueSlide Number 21Slide Number 22Slide Number 23Slide Number 24Slide Number 25Slide Number 26How do we know when we are done?How do we know when we are done?How do we know when we are done?Definition of DoneSlide Number 31What if my customer changes their mind?Slide Number 33How to Esri Manage this Agile Cycle?Using Agile in a Professional Services ProjectUsing Agile in a Consulting ProjectUsing Agile in a Consulting ProjectUsing Agile in a Consulting ProjectUsing Agile in a Consulting ProjectUsing Agile in a Consulting ProjectManaging ResourcesKeys to Successful Projects!ToolsRequirement Management ToolsTool to assist in Release PlanningUsing TrelloUsing GitHubUsing TFSMaking a DecisionSlide Number 50Slide Number 51Requirements and StakeholdersCase StudiesSmall ScaleCase Study – Small ScaleCase Study – Medium ScaleCase Study – Medium ScaleCase Study - Large ScaleCase Study – Large ScaleQuestionsSlide Number 61Slide Number 62Slide Number 63

Documents

Esri Best Practices: How to run an AGILE GIS project · project •Limited capacity, resources, and environment •Frequent turnover on project team •Medium or large size, mid to