Esri Best Practices: How to Run An AGILE GIS
ProjectJennifer Prather (esri), Betsy Leis (esri), and Joe Minus (NGA)
Who’s familiar with Agile?
https://www.youtube.com/watch?v=Wac3aGn5twc
• Watch the video
• Think about:
- What went wrong?
- What would you do differently?
How to Start…
Discuss similar
industriesAssess
workflows
Prioritize
workflows
Create a plan
Conduct
kickoff meeting
56
Choose
a life cycle
Launching your Location Platform Guide:
www.esri.com/LaunchGuide
5
The Agile Approach
Emerging Application Development | 1960’s – 1990’s
Requirements
Design
Implementation
Testing
Maintenance
`
`
`
`
• “I want something else”
1 + years6 months1.5 years1 year
`
Change Management
Process
Contract Amendment
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 | Terminology
User Story Epic
Velocity
Burndown Chart
AGILESprint\Iteration
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
ArchitectureDatabase
DesignWidget 1 Widget 2
Application
Hardening
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 Scrum
Master
Product
Owner
Developer Analyst System
Admin
Total
System
Architecture168
Geodatabase
Design272
Widget 1 272
Widget 2 360
Application
Hardening168
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
ArchitectureDatabase
DesignWidget 1 Widget 2
Application
Hardening
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 Shippable
Product Increment
2 - 4 Week
Sprint
Product
Owner
Scrum
Master
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 plan
egotiable. Details added via collaboration
aluable. Provides value to the customer
stimate-able. Too big or too vague = not estimate-able
mall. Can be done in less than a week
estable. Good acceptance criteria
A good user story uses the “INVEST” model:
I
N
V
E
S
T
Build for Value
Standish Group Study Reported at XP2002 by Jim Johnson, Chairman
Requirements evolve over time
Product Backlog
Wish List
Sprint Backlog
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…
treehouse
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
eth
od
Waterfall
Agile
Time
Meth
od
Waterfall
Agile
Time
Using Agile in a Consulting Project
Meth
od
Waterfall
Agile
Time
Using Agile in a Consulting Project
Meth
od
Waterfall
Agile
Time
Using Agile in a Consulting Project
Meth
od
Waterfall
Agile
Time
Using Agile in a Consulting Project
Meth
od
Waterfall
Agile
Time
Final Release
Using Agile in a Consulting Project
Managing Resources
Your Project
Plan A Plan B
Sprint
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
Tools
Waffle.io
Microsoft Team Foundation Server (TFS)
Requirement Management ToolsLicensed and Open Source
JIRA
Compare
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
https://businessanalystlearnings.com/technology-
matters/2017/7/4/a-list-of-free-requirements-management-
rm-software
Requirements and Stakeholders
THE 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 Study
Case Study - Large Scale
Product Backlog
Sprint Planning
Sprint Backlog
Potentially Shippable
Product Increment
2 Week
Sprint
Scrum of Scrum
Master
The team
Retrospective
Daily Scrum
Stakeholders
Tech LeadProject Manager
Customer’s PM
Project Manager
Daily Scrum
Daily Scrum
Sprint Planning
The team
Sprint Planning
The team
Scrum
MasterProduct
Owner
Scrum
MasterProduct
Owner
Scrum
Master
Product
Owner
Sprint Backlog
Sprint Backlog
Scrum of Scrums
~5 developers
1 tester
~7 developers
1 tester
~8 developers
1 tester
Contract Type $$ Value
FFP-LOE $20M
Customer Customer Customer Tech LeadTech Lead Tech Lead
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 Attendance
Print Stations Located in 150 Concourse Lobby
Tuesday12:30 pm – 6:30 pm
Expo
Hall B
5:15 pm – 6:30 pm
Expo Social
Hall B
Wednesday10:45 am – 5:15 pm
Expo
Hall B
6:30 pm – 9:30 pm
Networking Reception
Smithsonian National Museum
of Natural History
Download the Esri
Events app and find your event
Select the session
you attended
Scroll down to
“Survey”
Log in to access the
survey
Complete the survey
and select “Submit”
Please Share Your Feedback in the App