The document discusses challenges with traditional waterfall project management approaches and proposes using agile development methods like Scrum. It outlines key problems with waterfall including broken communication between stakeholders and developers. Scrum is presented as a solution with short iterative sprints, daily stand-ups, and emphasis on collaboration over documentation. User stories and acceptance criteria are also summarized as agile tools to clarify requirements.

1. Agile Development
&
Project management
Vishal Bardoloi

2. The Problem
• Despite everyone’s best intentions and efforts, software projects continue to fail
• This is in large part due to communication breakdowns
• Capturing software requirements is a communication problem between two totally different “types”
of people
• When business dominates, it mandates functionality and timelines with little concern that
developers can meet them
• When developers dominate, technical jargon and “cool features” take over the real needs of
the business

3. Case in point:Waterfall
• In traditional waterfall methods, decision-
making and information-gathering are done
only once - at the beginning of the project
• They take away options by making decisions
earlier than they need to be made
• They rely on ‘middlemen’ to communicate
between developers and stakeholders
• As a result, the communication process is
broken on most projects

4. The Agile Solution
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

5. Agile comes in different flavors... we will
be using the Scrum process

6. Scrum Overview
• Consists of a number of short iterations, or ‘sprints’
• Defined roles:
• Product manager - the business users’ representative
• ScrumMaster - facilitates the development and meetings
• Development Team
• Stakeholders - end users, project sponsors etc
• Meetings after each iteration
• Sprint review - to demo the development done in the past sprint
• Sprint planning - plan the next iteration’s deliverables

7. Scrum Development
• 2 to 4 week sprints
• During each sprint, the team will create a set of Production-ready features
• A Sprint review/planning meeting will be held after each sprint, where -
• Team will demo the functionality developed in the previous sprint
• Business users will prioritize the backlog for the next sprint
• Team will determines how much of the requested backlog they can finish in the next sprint
• No requirement changes in the middle of a sprint

8. Scrum Development

9. Scrum Roles
• Facilitator
• NOT a team lead (the team is self-organizing)
• Facilitates user story sessions and sprint meetings
• Removes roadblocks to the team’s success & protects them from distractions
• Development Team
• A group of people with cross-functional skills
• Design, develop, test, communicate
• Product owner
• Writes the user stories
• Prioritizes the backlog of user stories
• Signs off on deliverables

10. Scrum Roles
Customers Developers
Agree upon the length of each sprint
(this will stay the same throughout the project)
Select and prioritize the user stories to be
worked on for each sprint
Estimate the effort for each story
(in story points)
Agree upon the deliverables for each sprint
Specify the acceptance tests for each user
story to be complete
Deliver fully usable code that meets the
user story requirements
Make themselves available to resolve
questions from the development team
Identify and communicate issues early
Share responsibility for the final success of the project

11. Roles: Pigs & Chicken
“Pigs” are committed to the project.“Chicken” are merely involved.

12. Scrum Documents
• Project Backlog
• High-level document for the entire project
• Contains descriptions of all the required features, prioritized by business value
• Contains rough estimates of business value and development effort
• Sprint Backlog
• The requested features are broken down into tasks of 4-16 hours
• Estimates are set by the entire team
• Team members assign tasks to themselves, based on priority and their skill level
• Burn Down Chart
• A chart of the work remaining in the Sprint backlog
• Publicly available, updated daily with status (“To do”,“In dev”,“Done”)

13. The User Story tool is used to gather
requirements in Agile projects

14. • There are 3 parts to a User Story:
• Card - a written description of the story, used for planning and as a reminder to have a
conversation
• Conversation - discussions between customer and developer about the story, to flesh out
the details and define acceptance tests
• Confirmation - tests that determine when the story is completed
The User Story

15. The User Story
Card
•Created during the user story workshop
•Small, independent, negotiable, testable
•Meant to be high-level; serves as a reminder to have a conversation
Conversation
•Can occur at the sprint planning meeting or any time during the sprint
•
•The detailed requirements are fleshed out here, by the business user and
developer working together
Confirmation
•a.k.a.“Acceptance Tests” - these are tests that define the user’s
expectations and provides developers with a way to check if they’re done
•Initially defined during the sprint planning meeting; can change during the sprint
via conversations

16. The User Story
• Emphasizes verbal communication over written
• Spreads the decision-making process across the duration of the project
• decisions are made based on the information available
• decisions are made at the time when the functionality in question is being developed
• Lets you defer the details until you have the best understanding of what you really need
• Easily understood by both customers and developers

17. Good User Stories
• A bad story: “Create an Invoice”
• A good story: “As a (user role), I can (function) so that (business reason)”
“As a CCR, I can search for customers by their first and last name so that they don’t need
to look up their account number”
“As a Retail Ops manager, I can manage my team’s privileges so that they can void/delete/
resend invoices”
(Front of card)
As a CCR, I can search
for customers by their
first and last name so
they don’t need to look
up their acct number
(Back of card:
acceptance tests)
Test if multiple customers
have same name.
Test if customer name
doesn’t exist in system.
...