This document provides an overview of agile practices for product management. It begins with definitions of agile and its principles, which emphasize iterative development, collaboration between teams, and frequent delivery of working software. The document then outlines the typical agile procedure, including sprints, iterations, and product backlogs. It discusses various roles like product owners, coaches, and designers. It also covers practices for effective meetings, prioritizing work, designing user stories, testing, and ensuring quality through continuous delivery.

1. Agile practices
for product
management
@edolopez

2. Outline
1. What is Agile?
2. The procedure.
3. Effective Meetings.
4. Roles and the Agile Coach.
5. Caring about quality.
6. Prepare for feedback.
7. Growing you.

3. What is Agile

4. What is Agile

6. Agile
● Agile is a time boxed, iterative approach to
software delivery that builds software
incrementally from the start of the project,
instead of trying to deliver it all at once near
the end.
● Agile is all about teams working together to
produce great software products.
● Many modern teams are using a mixture of
Extreme Programming (XP), Lean, and
Scrum.

9. AGILE PRINCIPLES
1. Customer satisfaction by rapid delivery of useful software
2. Welcome changing requirements, even late in development
3. Working software is delivered frequently (weeks rather than months)
4. Close, daily cooperation between business people and developers
5. Projects are built around motivated individuals, who should be trusted
6. Face-to-face conversation is the best form of communication (co-location)
7. Working software is the principal measure of progress
8. Sustainable development, able to maintain a constant pace
9. Continuous attention to technical excellence and good design
10. Simplicity—the art of maximizing the amount of work not done—is essential
11. Self-organizing teams
12. Regular adaptation to changing circumstances
Beck, Kent; et al. (2001). "Principles behind the Agile Manifesto". Agile Alliance. Archived
from the original on 14 June 2010. Retrieved 6 June 2010.

10. Why from the software industry?
● Since 1957 software projects have been
tracked.
● Many similar circumstances and problems have
appeared with traditional methodologies as
Waterfall.
● Broad investment of resources for long term
planning projects with no relevant outcome.
● No alignation with users and customers
expectations.
● Creative work and job that is reference to other
industries in the same situation.

11. The procedure

12. Procedure

13. Procedure
Spikes
User Interface &
Design Testing
* Every agile procedure needs to adapt to the context of
the product, client and/or user.
Iterations
Product
Backlog
Sprint
Backlog

14. Procedure
Spikes
User Interface &
Design Testing
* Every agile procedure needs to adapt to the context of
the product, client and/or user.
Product
Backlog
(Sprints)
Iterations
Releases
Sprint
Backlog

15. A team works in iterations to deliver software.
Each iteration opens with planning based on
user stories and closes with a demo and
retrospective. The team works in a shared
workspace and starts their day with a daily
standup around their team board.
Software is created using Test-Driven
Development and Continuous Integration.
Some teams work in short one-week iterations,
while others work to a monthly cadence.

16. (Iteration)
In the context of the Scrum Methodology
Release 1
Release 2
Release N

17. Product design & development
The MVP
"The minimum viable product is that version of a
new product which allows a team to collect the
maximum amount of validated learning about
customers with the least effort." - Eric Ries

19. Agile working on Startups and MVPs

21. Estimates & Spikes
● The estimate is a practice to evaluate the
human efforts needed to achieve a goal
within a sprint, iteration, release or project.
● The best estimate is the one backed by
experts.
● In an agile context, planning poker is a very
common technique.
● Spikes are brief sessions to evaluate a
conflict or anything that needs to be
assessed among the team members.

22. Estimate points
● Size:
○ Many Agile estimates rely on “Relative Sizing” rather
than “Individual Sizing”.
○ Typically you will find fibonacci points. It doesn’t
matter how exact you are per story, but the
dependencies and complexity between the stories.
○ Other option is Ideal Days.
● Effort:
○ Amount of hours for a story, epic, theme.
○ Translation of size and points to hours.
● Velocity:
○ The amount of points/hours delivered per sprint or
iteration.

23. User Stories

24. As a (type of user)
I want (some goal/desire)
so that (benefit).
Examples:
1) As a Student
2) I want to purchase a parking pass
3) so that I can drive to school.
1) As a user
2) I want to search for my customers by their first and last
names.

26. Ron Jeffries wrote about the Three C’s of the user story:
1. Card: stories are traditionally written on notecards, and
these cards can be annotated with extra details.
2. Conversation: details behind the story come out
through conversations with the Product Owner
3. Confirmation: acceptance tests confirm the story is
finished and working as intended.
The Three C’s happen during the beginning of the an
iteration or a sprint to clarify anything and be on the same
page as the product owner.

27. Acceptance Criteria
Acceptance criteria define the boundaries of a user story, and are used to
confirm when a story is completed and working as intended.
For a payment user story, this could be an example:
1. A user cannot submit a form without completing all the mandatory fields.
2. Information from the form is stored in the registrations database.
3. Protection against spam is working.
4. Payment can be made via credit card.
5. An acknowledgment email is sent to the user after submitting the form.
Including acceptance criteria as part of your user stories has several benefits:
● They get the team to think through how a feature or piece of functionality
will work from the user’s perspective.
● They remove ambiguity from specs (requirements).
● They form the tests that will confirm that a feature or piece of functionality
is working and complete.

28. (Given) some context
(When) some action is carried out
(Then) a particular set of observable
consequences should obtain
An exemple:
1) Given my bank account is in credit, and I made no
withdrawals recently,
2) When I attempt to withdraw an amount less than my
card's limit,
3) Then the withdrawal should complete without errors or
warnings

29. Tests passing means the finalization of certain user story.

30. “Teams who are not yet very experienced with these ideas
often want to try use cases, spreadsheets showing
calculations, sketches of proposed window layouts,
even multi-page documents looking much like
conventional specifications. These may be useful in rare
cases, but looking back over the years I have almost never
found this kind of document to be ideal.”
- Ron Jeffries, XProgramming.com

31. Design
● Few information is available about agile
procedures and design (Lean UX).
● Nowadays products need to consider both
development and design elements in the
entire building procedure.
● As with the code, design needs to be tested.
● Design is one of the best ways to validate
products without investing lot of efforts.

32. Design in agile procedures

33. Artifacts

34. Backlog
● A list of user stories to be done.
● The priority is on the current sprint, then the
current iteration, then the current release.
The less prioritized features are on the
product backlog.
● A formal approach to prioritize the backlog -
“Grooming the product backlog”.

35. Prioritization
● A very important variable while planning
iterations and sprints.
● Take epics and themes as a reference to
prioritize.
● Best teams invest “10% of their time to
groom the product backlog” says Mike Cohn.

36. Prioritizing your backlog

37. ● Kano Analysis: It’s more useful to make a
little survey for 20 to 30 users.
● Theme Screening/Scoring: Select 5-9
features and assess the most important for
the next release.
● Relative Weighting: ROI, NPV, IRR
implementing new features.
● Expert Opinion: Delivery of new capabilities,
development of new knowledge, mitigation
of risk & changes in relative cost.

38. Effective Meetings

39. The Standup Meeting
● A common ritual building tech products.
● Goals for a daily stand-up meeting:
1. To help start the day well
2. To support improvement
3. To reinforce focus on the right things
4. To reinforce the sense of team
5. To communicate what is going on
As a mnemonic device, think of GIFTS:
Good Start, Improvement, Focus, Team, Status

40. http://martinfowler.com/articles/itsNotJustStandingUp.html

41. ● The meeting is about “Yesterday today
obstacles”
1. Any impediments in your way?
2. What are you working on today?
3. What have you finished since yesterday?
● It is stand up to keep it short. No more than
15 minutes. Track the time.
● Use the workspace as the place to have the
meeting.
● Have a backup with the team board.
● Used to start the planning of the entire day.

42. Retrospective meetings
● Start the retrospective by looking back to understand what
happened and why.
● Spend the second half of the retrospective looking forward
and deciding on a plan of action.
● Watch out for retrospective “smells” that are stopping your
team’s retrospectives from being effective.
● Find out what problems the team wants to fix most. Use dot
voting to focus on what the team has energy to work on.
● Don’t commit to more actions than can be completed before
the next retrospective. Even two or three actions completed
every iteration can have significant impact over several
months.
● If the actions from last retrospective weren’t done, find out
why before adding any more.

43. Retrospective format:
1. Review the goal of meeting, and remind the team of
the ground rules (5 minutes).
2. Create a timeline (15 minutes).
3. Mine the timeline for insights (15 minutes).
4. Select the topics to focus on (10 minutes).
5. Review the progress on previous actions (5
minutes).
6. Generate ideas for improvements (15 minutes).
7. Action planning (15 minutes).

45. Demo Session
The team needs to get together with their customer and check the following
items:
● Has the product been tested adequately?
● Are there any showstopper bugs?
● Is this a good time for end users to get a new release?
● Has the relevant documentation been done (such as release notes)?
● Does the team need to nominate a team member to support the release?
● Can the release be rolled back if problems are encountered?
● Human intervention may be required to release software, but this can be a
source of mistakes. Encourage the team to automate their deployment
process as much as they can.
Also:
● Have a plan B.
● The meeting is not always required.

46. Iteration & Release
Planning Sessions
● These session are needed to groom the
backlog and have a clear path to follow
during the next days.
● After the retrospective, decided actions need
to be considered when planning the next
iteration.

47. Choose a time: Establish a meeting time that works for the whole team, and give them plenty of notice about any
preparation they need to do.
Set up the space: Consider what kind of space you want for the meeting. Avoid meeting rooms with very large tables
because this spreads the team too far apart to see index cards on the table. You’ll also need something to capture
notes on, such as a flip chart or whiteboard.
Focus the meeting: Start the meeting by clearly stating the purpose of the meeting and giving a quick overview of the
agenda. Remind the team of any working agreements or ground rules for meetings.
Keep it flowing: Stay on your toes during the meeting, and ensure the conversations in the meeting stay on topic and
are productive. When you act as a “facilitator,” your aim is to make the meeting easier for the people in it—like oil in an
engine. You keep the meeting moving and focused on producing useful output. This is easier to do if you are not taking
an active position in the discussion— step back to maintain a neutral position. If you need to offer an opinion, then
explicitly step out of the facilitator role.
Encourage everyone to participate: Make sure everyone’s opinion is heard. This means only one person talking at a
time. When someone is making broad generalizations, it can help to ask for examples and ask clarifying questions to
draw out the details.
Summarize key points: Before you write up any points on the whiteboard, check to see you have really understood
the point by repeating what you heard.
Close the meeting: When you bring the meeting to a close, make sure that outputs are recorded appropriately. Taking
digital photographs is a quick way to capture whiteboard sketches and meeting notes.
To improve next time, ask for feedback on your facilitation of the meeting. You can do this by asking everyone for
suggestions at the end of the meeting or by asking someone to observe how you run the meeting and then discussing
improvements with them after it finishes.
Questions to guide: Five whys, to resolve problems, Reflective questions, Thinking questions, Ask for help
Tips to make meetings effective

48. Daily
Standup
Daily
Standup
Daily
Standup
Daily
Standup
Daily
Standup
Daily
Standup-
DESIGN
SPIKE
Daily
Standup
Demo
Session
Daily
Standup
Daily
Standup
Daily
Standup
Daily
Standup
Daily
Standup
Daily
Standup
Daily
Standup
Daily
Standup
Daily
Standup
Daily
Standup
Daily
Standup
Daily
Standup
Release-
Iteration
Planning
Retro
spective
Retros
pective-
Iteration
Planning
Retro
spective
A proposal for calendarization
Beginning
of project
Retros
pective-
Iteration
Planning
Demo
Session
2 week
sprints
Sprints are
iterations.
Not all
iterations
are sprints

49. Roles

50. Roles
1. Designers
2. Developers
3. Agile Coach / Scrum Master
4. Product Owner.
5. * The Client (Project stakeholders in XP)
This will be the TEAM.
* Can be excluded from meetings, the product owner will have the responsibility

51. (Product Owner)

52. A team needs to...
● Build trust.
● Have its own team space.
● Celebrate success.
● Be self motivated.
● Be cross-functional.
● Beware of incentives.
● Communicate constantly.
● Be co-located.

53. Coaching
● The art of Agile coaching is understanding
the situation, the values underlying Agile
software development, and how the two can
combine.
● Your goal is to grow a productive Agile team
that thinks for itself rather than relying on
you to lay down the Agile law.
● Patience is one of the most important
qualities of a coach. Don’t expect instant
perfection from the team; change takes time.

54. Habits to develop as an Agile coach:
1. Lead by example.
2. Keep your balance.
3. Set a realistic pace.
4. Mind your language.
5. Learn as you go.
-- Show that you are part of the team by talking from a team perspective using
“our”/“we”/“us” rather than “I”/“you”/“they.”
-- Avoid making sweeping generalizations. Don’t use words like “never,”
“always,” “right,” and “wrong,” because doing so can discount the situation at
hand. Try hard not to dismiss past practice by saying it was wrong or incorrect;
this creates bad feeling, and people may feel they’ve lost face.
-- Beware of putting people in boxes by using labels and talking about “the
developers” or “management.” Try to use people’s names.

56. We’re the experts
Nonetheless, the relationship between
customers and developers is crucial because
they need to work together to create the best
product.
Gold cards provide a way for the team to
present new product ideas to their customer to
make it a product they’re proud of.

57. Caring about quality

58. Practices
● Continuous Delivery
● Continuous Deployment
● Continuous Integration
● Continuous Monitoring

59. Continuous Delivery
● A series of practices designed to ensure that
code can be rapidly and safely deployed to
production by delivering every change to a
production-like environment and ensuring
business applications and services function
as expected through rigorous automated
testing.
● PaaS: Heroku, Digital Ocean, Docker.

60. Continuous Deployment
● Continuous deployment is the next step of
continuous delivery: Every change that
passes the automated tests is deployed to
production automatically. Continuous
deployment should be the goal of most
companies that are not constrained by
regulatory or other requirements.
● Tools depend on Continuous Integration.

61. http://blog.crisp.se/2013/02/05/yassalsundman/continuous-delivery-vs-continuous-deployment
Continuous Delivery vs. Continuous Deployment

63. Continuous Integration
● A toolchain and a discipline.
● CVS, Pull Requests. Everyone has a copy of
the repository.
● Continuous code integrations.
● Automation of new deploys, new features,
new acceptance tests.
● Tools: Travis, Jenkins, CircleCI.

64. Continuous Monitoring
● Uptime & Downtime: https://uptimerobot.
com/
● New Relic: http://newrelic.com/
● Every trustful provider has its status.*.com

65. Growing You

66. Growing you
Learning from others and teaching to others
are the best sources of knowledge available.

67. Work out how you learn best, and set aside
time to do it:
● Commit to read one technical book per
month.
● Start your own blog.
● Contribute to an open source project.
● Post once a day to a community mailing list.
● Listen to a podcast on your way to work.
● Spare one evening a month to attend an
interest group.

68. Additional Information

69. Methodologies
● Product owner from Scrum is very important.
● Pair programming for code review is coming
from extreme programming.
● Refactor when you can comes from extreme
programming.

70. Tools
1. Pivotal Tracker
2. Basecamp
3. Hangouts from Google.
4. Skype
5. Github/Gitlab
6. ...

71. Books
● Agile Coaching
● Lean UX
● Lean Startup
● Planning Extreme Programming
● Don’t Make me think

72. References
● It is not just standing up: http://martinfowler.
com/articles/itsNotJustStandingUp.html
● The agile manifesto: http://agilemanifesto.
org/
● Agile for beginners: http://www.agilenutshell.
com/
● Prioritizing your product backlog: http://www.
infoq.com/presentations/prioritizing-your-product-
backlog-mike-cohn

73. ● Tips for prioritizing your backlog: http:
//productowner.net/2012/01/31/tips-prioritization-
product-backlog/
● Artifacts in user stories: http://www.
agilemodeling.com/artifacts/userStory.htm
● Essential XP: Card, conversation and
confirmation http://xprogramming.
com/articles/expcardconversationconfirmatio
n/
● Acceptance criteria references: http://www.
boost.co.nz/blog/2010/09/acceptance-criteria/

74. ● http://guide.agilealliance.org/guide/gwt.html
● http://epf.eclipse.org/wikis/openup/core.
mgmt.common.
extend_supp/guidances/guidelines/agile_esti
mation_A4EF42B3.html
● http://blog.crisp.
se/2013/02/05/yassalsundman/continuous-delivery-
vs-continuous-deployment
● http://puppetlabs.com/blog/continuous-delivery-
vs-continuous-deployment-whats-diff
●

75. Thanks :]
Questions?
CEO - @edolopez
edolopez@icalialabs.com