Impact Mapping: To understand the requirements and stakeholders

Agile The culture of Purpose and continuous improvement

Being Agile: People collaborating together to solve a problem or achieve a goal with
high quality at a sustainable pace.
Incremental and Iterative Delivery
Frequent Customer Feedback
Continuous Planning
Continuous Improvement
Flow & Emergent Design
Autonomous Team
Cross-functional team
Its basically the gist of what Agile Manifesto and principles say:
1. Incremental and Iterative Delivery
2. Frequent Customer Feedback to improve the quality of the product.
3. Flow and Emergent Design to improve the quality of product and ability to
respond to change.
4. Evolving Process to improve quality of product and people.
5. Continuous planning to improve predictability
6. Autonomous team to improve self-organization
7. Cross-functional team to improve collaboration
Three pillars uphold every implementation of empirical process control:
transparency, inspection, and adaptation.
Scrum prescribes four formal events for inspection and adaptation, as described in
the Scrum Events section of this document:
Sprint Planning
Daily Scrum
Sprint Review
Sprint Retrospective

The Product Owner

The Product Owner is the sole person responsible for managing the Product Backlog.
Product Backlog management includes:
Clearly expressing Product Backlog items;
Ordering the items in the Product Backlog to best achieve goals and missions;
Optimizing the value of the work the Development Team performs;
Ensuring that the Product Backlog is visible, transparent, and clear to all, and
shows what the Scrum Team will work on next; and,
Ensuring the Development Team understands items in the Product Backlog to the
level needed.

Scrum Master Service to the Development Team

The Scrum Master serves the Development Team in several ways, including:
Coaching the Development Team in self-organization and cross-functionality;
Helping the Development Team to create high-value products;
Removing impediments to the Development Teams progress;

 Facilitating Scrum events as requested or needed; and,

Coaching the Development Team in organizational environments in which Scrum
is not yet fully adopted and understood.

Scrum Master Service to the Organization

The Scrum Master serves the organization in several ways, including:
Leading and coaching the organization in its Scrum adoption;
Planning Scrum implementations within the organization;
Helping employees and stakeholders understand and enact Scrum and empirical
product development;
Causing change that increases the productivity of the Scrum Team; and,
Working with other Scrum Masters to increase the effectiveness of the
application of Scrum in the organization.
Agile manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to challenge over following a plan
Scrum provides: Roles, Artifacts, and Meetings
Roles:
Product Owner:
Responsible for ROI
Final arbiter of requirements questions
Focused more on the what than the how
Scrum Development Team:
Cross-functional team
Attempts to build potentially shippable product increment every sprint
Collaborates
Self-organizing
4-9 people
ScrumMaster:
Has no management authority
Doesnt have a project role
Facilitator
ScrumMaster protects the team from distractions and interruptions, gets things out
of the way teams natural self-organization, moves impediments effecting the team,
facilitates the process, helps team teach people how to use scrum, promotes
improved engineering practices, enforces time-boxes, and provides visibility.
Artifacts
Product Backlog: Product Backlog Item prioritized by the product owner. Everything
we might ever do.

Force ranked Only one thing in the top position.

Sprint Backlog: What we have agreed to do during the current sprint. It has
committed product backlog items representing the what, and the sprint tasks
representing the how.
Meetings
4 meetings + 1.

Sprint Planning Meeting: Product increments selected during the sprint planning
meeting. Team and the product owner negotiate which product backlog items would
be committed to the sprint. The team pulls the top priority items from the product
backlog, commits them to the sprint backlog, breaks them into smaller tasks, and
decides if it is the right amount of work for them to do, and if they are clear about
what they are going to do.
Daily Scrum Meeting: During sprint execution, the team meets once per day for 15
mins standup for daily scrum. The team just reports to each other.
Sprint Review Meeting: At the sprint review meeting, the team demonstrates a
potentially shippable product increment to the product owner and stakeholders.
Product owner would decide which items are done, and which items didnt meet the
acceptance criteria. We can measure velocity, and get feedback from the
stakeholders about how we are doing with the product.
Sprint Retrospective Meeting: Every sprint ends with the sprint retrospective
meeting for the team to inspect and adapt their own process. What went well, what
could be improved. We give feedback to each other.
Backlog Refinement Meeting: The team and the product owner get together and
look ahead a little bit into the next few items in the product backlog, the items that
are candidates for the next couple of sprints. Break the big product backlog items
into smaller product backlog items like user stories, so that we can imagine doing
few of them in one sprint. Gets input about prioritization, consider dependencies
etc.

Backlog Refinement Meeting (a.k.a Product Backlog Grooming, Backlog

Estimation, Story Time)
Done a couple of work days before the next sprint planning meeting. 2 hour time
box.
Any work that represents business value or consumes time and attention from the
team may be worth listing in the product backlog.
One objective of the Backlog Refinement Meeting is to create PBIs that are
INDEPENDENT, NEGOTIABLE, VALUABLE, ESTIMABLE, SMALL, TESTABLE.
Product Owner is responsible for Product Vision and ROI.
Propose using Estimation Cards to get a better cross section of opinions about the
effort to get that PBI into potentially shippable form.
Epic can be split into several distinct user stories. This is one of the purposes of
Backlog Refinement Meeting. A well-formed PBI toward the top of the backlog is no
bigger than a quarter of a sprint and ideally smaller than that. It is often useful to
identify WHO, WHAT, and WHY in a product backlog item, i.e., As a student, I can
see my grades online so that I dont have to wait until I get to school to know
whether Im passing.
Well leave room to add some acceptance criteria.
Backlog refinement includes:
estimation of effort
clarification of requirements
Decomposition of large PBIs into smaller ones (Epic to user stories)
Sprint Planning
ScrumMaster would facilitate this meeting. During this meeting, the product owner
and development team will agree to sprint goals and negotiate which items from
the product backlog will be committed to sprint backlog. We have a 4 hour time box
to plan a 2 week sprint. Also during this meeting, the team will come up with an
initial list of tasks necessary to complete the committed PBIs. According to agile
project management with scrum, only 60% of the tasks are likely to be identified
during the sprint planning meeting. Other tasks, such as unanticipated
dependencies, will be discovered during speint execution.
In the original scrum book, this is a 2-part meeting. Sprint planning part 1 is for
committing to PBIs. Sprint planning part 2 is for coming up with the tasks. This is
important for multi-team scrum. Since we are only one team, and the product owner
is available the whole meeting, we can mix up the two parts.
Scrum teams attempt to build potentially shippable product increments every
sprint. This requires every sprint to have a mix of analysis, design, implementation,
testing, integration, and even deployment.

If anyone asks you to do anything unrelated to our sprint goals, send them to
product owner so he can add it to the product backlog. He wont interrupt the spring
unless it is an emergency.
You have 4 hours to plan a two-week sprint, and 1 day for a 30 day sprint.
Definition of Done:
a) Code has been written by pairs, or at least reviewed by other team members
b) Manual, exploratory analysis has been conducted
c) Regression tests for new functionality run automatically with every build
d) Messy poorly designed code has been cleaned up through refactoring
e) Duplicate code has been removed through refactoring
f) All previous regression tests pass
g) Checkout and build are fully reproducible, typically with one or two
commands
So it is the code that properly tested, refactored, potentially shippable
A lean principle behind scrum is to limit the work in progress. Humans dont
multitask efficiently. Too much WIP actually slow things down.
Daily Scrum Meeting
ScrumMaster is going to help with the daily scrum meeting. It is done at the same
time, same place, each day, standing up for 15 mins.
At this meeting, each team member will report to the rest of the team answers to
these 3 questions:
a) What will I do today (or before the next scrum meeting)?
b) What did I do yesterday (or since the last scrum meeting)?
c) What impedes me (blocks in progress, reduces efficiency, etc.)?
7 obstacles to Enterprise Agility:
1) Nave resource management
2) Teams organized by functional specialization
3) Teams organized by architectural components
4) Distractions
5) Reluctance to continuously refine, reprioritize, and rescope
6) Rampant technical debt
7) Lack of commitment to transformation
Scrums rules allow the product owner to either attend, or not attend, the daily
scrum.
Sidebar topics can be discussed after the meeting.
Test Driven Development: Includes writing a few lines of failing code, then writing a
few lines of product code and passing the failing tests, then refactoring to improve
the design without changing the behavior.
Sprint Review Meeting

Sprint review meeting is open to outside stakeholders. The highlight of every sprint
review meeting is a live product demonstration. After that the product owner will
declare which of the PBIs committed to the sprint meet the acceptance criteria
agreed at the sprint planning meeting and whether sprint goals were met. When the
product owner considers items done, theyll be counted as velocity. The only
purpose of velocity is to help the Product Owner make forecasts. Items that are not
done or almost done will be moved in entirety back to the product backlog.
Lastly, well listen to feedback from the stakeholders which may result in new
product backlog items for the product owner to prioritize according to his vision.
Agenda:
1) Product demonstration
2) Product Owner declares whats done
3) (Optional) Measure velocity
4) Stakeholders feedback
The sprint review meeting is a key inspect and adapt mechanism in Scrum. So we
want to avoid things that could interfere with transparency.
Sprint Retrospective Meeting
Empirical feedback from the Sprint Review Meeting should influence the Sprint
Retrospective discussions. Sprint review meeting was our chance to inspect and
adapt the product; sprint retrospective meeting is the teams chance to inspect and
adapt its process.
An effective facilitator sometimes uses status leveling techniques to reveal a
greater cross-section of viewpoints from the team. (Safety check, Basic
retrospective, Focused conversation principles, Silent writing, Timeline
retrospective)
Classic Scrum Retrospective:
What went well?
What can be improved?
What did we learn?
What still puzzles us?
Focused Conversion Principle:
Members often begin solving problems by suggesting solutions before agreeing on
the problem or its causes. Follow ORID
Objective questions (What happened?)
Reflective questions (How do we feel about it?)
Interpretive questions (What does it mean?)
Decision questions (What are we going to do about it?)
Decisions come last.
Silent Writing:

Timeline retrospective:
Decisions: