Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Going Agile with Scrum

No description
by

Allison Lanager

on 6 November 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Going Agile with Scrum

Going Agile with Scrum
What does it mean to be agile?
Why are
we
doing this?
Constantly evolving requirements
We are dependent upon new and evolving technology
We are depended on by new and evolving applications
Cloud customers will have different needs
We need to prioritize and deliver what matters most
Short timeline
Hundreds of features
We can't do them all
Regular feedback and adaptation is critical
Successfully delivering the wrong thing is still a failure to deliver
Focus on the core principles
Teamwork and collaboration
Responding to change
Regular interaction with the "customer"
Frequent delivery
Sustainable pace
Functional software as measure of success
Fun Fact:
The Waterfall software development process comes from a paper in which the author was offering criticism against the approach.

I believe in this concept, but the implementation described above is risky and invites failure.

His recommendation?

An iterative and incremental approach, in which projects should pass through the development sequence at least twice.
So what is Scrum?
Process for incremental product development
Maximizes team's ability to respond to change
Provides a means to estimate project timelines
Encourages feedback on the process itself
Agile frameworks are only meant to guide
Adapt the techniques to suite the team
Focus on the principles and how to meet them
Agile development is
flexible
Quick Introduction To Scrum
Wait, this isn't the product owner?
Often has more specific domain knowledge
Deep understanding of customer requirements
Answers development questions
Identifies missing user stories and feature gaps
Provides mockups for user stories
Reviews and offers feedback on UI and flow
Self-organizes within the team to perform work
Assists the product owner
Break down user stories into tasks
Prioritization
Communicates progress consistently
Provides feedback on both work and development processes
Supports team success
Works across many areas
Often executive level management
Provides high level goals and customer needs
Informs team of long term organizational goals
Periodically reviews product and provides feedback
Has the overall vision of the product
Interacts with the customers, stakeholders, etc
Maintains the backlog and prioritizes it
Identifies and adds user stories
Defines acceptance criteria for the user story
Verifies that these criteria are met
Business Analyst
Agile development coach
Gets road blocks out of development's way
Authority on the agile process being followed
Sets up and handles sprint planning, review, retrospective
Shields development from outside interference
Including the product owner
Push for understanding and change within the organization
Scrum Roles
May be actual company customer, or internal team
Participates in sprint review session
Delivers feedback on functionality and design
Provides priority information to Product Owner
Identifies gaps in user story list and product backlog
Scrum Master
Product Owner
Developer
Stakeholder
Customer
User Stories
As a <user>, I want <functionality>, so that <goal>.
Written from a specific user's point of view
User Story workshops are used to prepare initial list
Starts as a simple sentence
No implementation details
No UI assumptions
Flexible to change and still meet goal
Typically estimated in story points
As it approaches the top of priority queue it is prepared
Broken into smaller stories if needed
User story artifacts added
Only complete if it meets the Definition of Done
Story Points
Rough estimation of work to be done
Often thought of in terms of 'ideal days'
Teams should identify buckets
1, 2, 3, 5, 8, 13, 20 days...
Break a story down before assigning it to a sprint
<= 5 story points for us
Q: What happens if we don't complete the story in the sprint?

A: It counts for 0 story points that sprint.
Q: What if we estimate 3 story points, and it turns out to be 8 days?

A: It counts for 3 story points. Same if it turned out to be 1 day of effort.
Q: Why is it important to break them down?

A: So estimated velocity is less volatile, since you only get credit for completed stories.
Story Artifacts
Not the same for all teams, but usually:
Acceptance criteria
Requirements specific to the user story
Mockups
Work flow details
Documentation of conversations and decisions if needed
Definition of Done
Set by the team
Checklist to be met before story counts as complete
Usually technical tasks, such as:
Code commented and checked in
Unit tests complete and all pass
Meets acceptance criteria
Code analysis performed
Q: What is the difference between DoD and Acceptance Criteria?

A: Acceptance criteria is user story specific, and usually business logic. Definition of done applies to all stories and is for production quality.
Q: When do we close a jira?

A: When all acceptance criteria, constraints, and definition of done requirements are met.
Tasks
The technical items needed to complete a story
Add the database tables
Create the UI
Extend the framework
Must meet definition of done independently
Estimated individually in hours
Remaining work effort updated regularly
Daily Burn Down Chart
Analyze if the
sprint
will be completed on time
Shows effort remaining in sprint
Updated at least once a day
Release Burn Down Chart
Analyze if the
release
will be completed on time
Shows all remaining work effort
Updated at the end of each sprint
Never assume velocity based on this chart
A small decrease may indicate newly added scope
Daily Scrum Meeting
All team members attend
Limited to 15 minutes
Answer the following questions:
What did I do yesterday?
What will I do today?
What is blocking me from completing work?
Scrum Master should listen for issues they need to assist with
But team is not 'reporting' to scrum master
They are reporting to each other
Sprint Review
Purpose is to inspect the product
Open to stakeholders, customers, etc
New functionality is demonstrated
Feedback is provided, resulting in:
New stories
Updating priority

Note: We will be recording these and making them available.
Sprint Retrospective
Purpose is to inspect the process
Limited to the team
Answers the following questions:
What went well?
What went poorly?
How could we improve?
Real focus is to get team talking in a safe environment
Identify what is holding them back
Follow up on solving those issues
Modeling Post-Sprint Activities
Update demo server
Regression tests, update bug list
Update release burn down
Update user story status
Identify project timeline impact
Velocity Chart
Analyze how much work can reliably be done in a sprint
Tracks story points completed each sprint
Updated at the end of each sprint
Can be used to estimate project completion dates
Q: How does this tell us when we can release?

A: It tells us how many story points we can fit into a single sprint, which means we can estimate how many sprints it will take.

We also know how long a sprint is, so we can estimate a date once we know how many we need.
Q: What if a story point doesn't match up with an ideal day?

A: That's okay. If we are consistent about how we estimate story points, it won't matter what a story point is equivalent to. Velocity will tell us how many we can do.
Q: What about employee holidays? Customer issues? Build setups? How is this accurate?

A: In most cases, external work load, PTO, etc, will be roughly equal each month over time. The velocity will account for this by being lower than 'ideal'.

Christmas holidays could be an exception. :)
Product Backlog
Contains more than user stories
Epic user stories
Bugs
Technical tasks
Research spikes
All items existing in backlog are roughly estimated
Where are we today?
Principles:
Teamwork and collaboration
Responding to change
Customer interaction
Frequent delivery
Sustainable pace
Functional software
Process:
Team Roles
Product backlog
Definition of Done
User Stories
Sprint Planning
Sprint Development
Scrum Meeting
Review
Retrospective
Full transcript