We usually work with clients using time and materials, fixed price per release, or fixed price for the entire project. For the first two approaches, we use scrum artifacts like the product backlog and sprints. The product backlog contains prioritized user stories, bugs, and improvements. We refine stories in refinement meetings and plan each sprint in sprint planning meetings. Daily standup meetings keep the team synchronized. At the end of each sprint, we demo completed work and retrospect on our process in retrospective meetings.

2. How we sell to clients
We usually work in some of these ways:
● Time and Materials
● Fixed price per Release
● Fixed price for the entire project.
For the first two we use the same scrum artifacts to keep the work organized.

3. Time and Materials
Our clients pay us for the time we spend working on the project.
This is done by an understanding by the client that the requirements are going to
evolve in the future and in fact are going to be discovered by the team and himself.
This type of project can't live without trust. We need to cultivate and maintain
trust by:
● Continuously deliver valuable work.
● Make them feel we are there! (aka frequent and good communication).
● Being honest.
● Work in a professional way.

4. Per Release
Quick definition:
Product = [Releases];
Release = [Features];
● A well defined document with functionalities.
● Should be a small set of functionalities (no more than 3 weeks).
● Each release should be production ready.
● Each pre-release should be fully functional.
● Usually clients prefers this approach (mostly at the beginning).
● Unpaid free time between each release.
● Bugs vs New features (even smaller!) detect them.

5. Differences between ways of selling:
● Entire product != set of releases.
○ Time in planning
○ Distribution of planning
○ Time to obtain feedback
○ Financial process is different, more controlled.
● Set of releases != time & materials
○ Each release is with the same team
○ Planning is more fluid (no need to validate things to continue working)
○ Trust environment and teammate
○ Engagement of the team

6. Our Framework

7. Roadmap (Product backlog)
● It’s a path to build the product you want. It
should tell a coherent story about the likely growth
of your product, being as much realistic as
possible.
● It should tell what is needed to build not how.
● Should be prioritized and the top priority items
should be:
○ very specific
○ valuable
○ testable
○ estimated.

8. Roadmap (Product backlog)

9. Roadmap (Product backlog)
● Detailed Appropriately:
○ Not all the items in the product backlog will be at the same level of
detail at the same time.
○ This should happen in a just-in-time fashion (refinement meetings)
○ We need to find the proper balance:
■ If we refine too early, we might spend a good deal of time figuring out the
details, only to end up never implementing the story
■ If we wait too long, we will impede the flow of PBIs into the sprint and
slow the team down.

10. ● Help balance the upfront planning and the
just in time planning.
● Set of features in each release
● At least 2 or 3 releases in roadmap +
backlog
● Each Release can be:
○ Fixed scope (Once the set of
functionalities are done, you can deliver
the product)
○ Fixed date to deliver (dynamically
change the scope in order to deliver on
time)
Roadmap: Releases - definition

11. ● Each Release should not be very big, in fact is
good to be around 3 weeks of work as max.
○ This way we avoid:
■ complexity of the release with more
potential bugs.
■ too much planning
■ spend to much time testing
○ We gain:
■ we add value to the product frequently
■ Good perception in client and users
about the product
■ Less complexity, less testing, etc
Roadmap: Releases - recommendations

12. ● It’s important to have as many features as
possible (and reasonably) estimated.
● Each Release is a potential increment of value
to the project and should be production ready
(stable and well tested).
● It’s very important also to balance correctly
small features that are very important and
add a lot of value vs big features that do not
add as much value considering the time they
take. So on each release try to discuss and
evaluate small but important features too.
Roadmap: Releases - recommendations cont

13. ● It’s a good idea to use Epics to group features
of the same kind that are of interest to the team.
● Sometimes it’s good to have one document per
epic explaining the functionalities and behaviors.
● Some examples of Epics could be:
○ User profile
○ Friends management
○ Suggestion system
○ Technical debt
Roadmap: Releases - recommendations cont

14. Roadmap: Releases

15. Refinement meeting
It’s a meeting to clarify as much as
possible the top priority tasks that we
will work on soon (generally the next
release).
In this meeting we should divide big
stories in smaller ones, ask as much
questions as we have, create new
stories if needed, etc.
★ ~ Every Thursday
★ ~1 hour of duration

16. Refinement meeting: definition
● Balance between “up front” planning and
“just in time planning”.
● Try to understand all the needed work and
we do a sort-of mini planning adjusting
stories and things to do for the next release.
● What is needed and not how.
● This meeting is very important because we
try to define things while we still have
things to work. So we are asking, studying
and giving time for the client or product
owner to answer the questions without
urgency.
● All the team should be in the meeting so
topics can be discussed and all can
be in the same page.

17. Refinement meeting: key actions
● Understanding what next
● Discussing with the team
● Asking questions to client (talking or
tool)
● Refining stories (1 to n)
● Estimating
● Identifying and adding new stories
● Removing stories

18. Refinement meeting: content
● We should organize our list of features (Product backlog items) in:
○ Stories: -main citizen in the framework-, describes the functionality that the
system brings considering the role of the user, goal and reason.
The basic schema should be:
As a <type of user>, I want <some goal> so that <some reason>.
○ Bugs: There are bugs inside the sprint about stories in the sprint and bugs
or defects outside the sprint. Outside Sprint bugs should be sized if we
place them in a PBI.
○ Improvements: Functionality that already exist but that need us to change
some behaviors, etc.
○ Technical staff: Technical depth to be addressed, architecture
modifications, etc.

19. Sprint planning
It’s a meeting to organize the work we
will do in the next sprint.
In this meeting we should organize and
think about how we are going to do
things. That’s why we should create tasks
for each story describing the steps to do
in order to complete the story.
★ ~ At the beginning of the sprint
★ ~As much time as the team needs

20. Sprint planning
● Divide the stories in tasks and assign the sum of each task to the story.
● Create ~small tasks that could be done in <= one day.
○ Goal for the day.
○ Plan in depth how to do the story.
○ Realize and organize new questions.
● The sum of the stories <= average of story points per sprint.
● It’s good to leave ~15% for unexpected things, testing, etc.
● Use tools the right way
○ Allows us to use reports correctly
○ Keeps all the team aligned and updated
○ Allows us to correctly filter features by type, priority, etc

21. Sprint planning
● Sprint backlog vs pre-assigned features.
● Scope of Sprint backlog can vary if needed (agile!)
○ we can add important bugs
○ replace features
○ adjust capacity
● Team is going to know itself and discover their capacity progressively
○ avoid too much things to do
○ allows planning and the team to be more precise

22. It’s a meeting to let all the team know on
what we are working.
This meeting aims to sync the team and
fire possible warnings if they are
discovered.
Daily meeting
★ ~ Everyday
★ ~15 minutes

23. Daily meeting
○ It’s good idea if it's talked.
○ Helps the client to:
■ see activity everyday
■ avoid unprioritized work
■ add some important comments to tasks
○ Helps us organize ourselves and realize what we did and what
we have to do.
○ Discuss daily issues or times for meetings, etc

24. Think honestly about how you have been
working in the sprint. This can include all
aspects like: code quality,
communication, synchronization,
development process, the product,
suggestions, etc
There are no restrictions.
Retrospective meeting
★ ~ At the end of the sprint
★ ~1 hour of duration máx

25. ○ List the things that went well, and celebrate them, feel good!
○ List of things we can improve.
○ Try to focus on one or two of them, no more.
○ Review metrics, and goals of previous retrospectives,
■ talk about velocity
■ burndown chart
■ etc.
○ Try to improve and learn based on experience.
○ Involve the client and get feedback
Retrospective meeting

26. A meeting to share all the progress
we have done with the client. And
much more!
Demo meetings ★ At the end of each sprint
★ ~1 hour of duration max

27. ○ Prepare the demo (clients loves demos and here is where they really see
our work)
○ All the details from a functional point of view
■ main functionality
■ validations
■ animations
■ speed
■ all
○ Just talk about the things that add value (aka, not bug unless asked)
○ Explain things, ask for opinions.
○ Ask about the future, what’s next?
○ Ask at least one question :)
○ Good to discuss the demo with a second person after it.
Demo meeting

28. Calendar

29. Be Agile
○ Forget all, in the end, the most
important thing over the process and
tools are:
■ work done! tasks done, working
product!
■ good communication with your
team and good feelings!
■ ask questions, think further!
■ adapt and try to adjust things, be
flexible!

30. References
● http://es.slideshare.net/UpekhaVandebona/scrum-product-backlog-49209630
● http://www.romanpichler.com/blog/10-tips-creating-agile-product-roadmap/
● http://www.slideshare.net/BosniaAgile/scrum-sprint-structure-workshop-by-nermina-durmi-i-kemal-
bajramovi
● http://es.slideshare.net/UpekhaVandebona/estimation-and-velocity-scrum-framework