1.
Agile Fundamentals
and Best Practices
Filippo Zanella
January 29th, 2015
Sellf s.r.l.

2.
OUTLINES
1. FUNDAMENTALS
- WHY AGILE
- TEAM
- PROCESS
2. PRACTICES
- SPRINT PLANNING
- USER FEEDBACK
- TESTING
- SALES & MARKETING
3. TRELLO

3.
INTRODUCTION
I made this slide to recap to my team at Sellf some key
concepts related to the agile (software) development.
The presented fundamentals are a summary of Scrum
directly picked from Wikipedia.
The content of the agile best practices is a (fairly faithful)
transcription of the “Agile Best Practices” screencast
presented by Jay McGraven at Codeschool.
The use-case of Trello as a tool for product management
and project tracking comes from my experience at Sellf.

4.
FUNDAMENTALS

5.
WHY AGILE
STAYING FOCUSED IN DELIVERING REAL
VALUE TO THE COMPANY
• No wasting time on unneeded planning docs
• No delivering features that do not fit (quite well)
customers needs
source: Jay McGraven at Codeschool

6.
TEAM

7.
PRODUCT OWNER
PRODUCT OWNER writes customer-centric items
(typically user stories), ranks and prioritizes them,
and adds them to the product backlog
• demonstrates the solution to key stakeholders (demo)
• announces releases
• communicates team status
• organizes milestone reviews
• educates stakeholders in the development process
• negotiates priorities, scope, funding, and schedule
• ensures that the Product Backlog is visible, transparent, and clear
source: Wikipedia

8.
DEVELOPERS
DEVELOPMENT TEAM is responsible for delivering
potentially shippable increments of product at the end of
each Sprint (the Sprint Goal).
A Team is made up of 3–9 individuals with cross-functional
skills who do the actual work.
• analyse
• design
• develop
• test
• technical communication
• document
source: Wikipedia

9.
SCRUM MASTER
SCRUM MASTER who is accountable for removing
impediments to the ability of the team to deliver the
product goals and deliverables
• helping the Product Owner maintain the product backlog
• determine the definition of done for the project
• coaching the team within the Scrum principles
• promote self-organization within the team
• remove all impediments to the team's progress
• facilitate team meetings to ensure regular progress
source: Wikipedia

10.
PROCESS

11.
SPRINT
The sprint is an effort restricted to a specific duration
The duration is fixed in advance for each sprint and is normally
between one week and one month, although two weeks is typical
Scrum emphasizes working product at the end of the Sprint that is really
“done". in the case of software, this means a system that is integrated,
fully tested, end-user documented. source: Wikipedia

12.
MEETINGS
Each sprint is started by a planning meeting. The aim is to define a sprint backlog where the
tasks for the sprint are identified and an estimated commitment for the sprint goal is made.
Sprint planning meeting at the beginning of the sprint cycle (every 7–30 days)
• Select what work is to be done
• Prepare the Sprint Backlog that details the time it will take to do that work, with the entire team
• Eight-hour time limit for a 30-days sprint
- (First four hours) Entire team: dialogue for prioritizing the Product Backlog
- (Second four hours) Development Team: hashing out a plan for the Sprint (Backlog)
Daily scrum meeting (standup meeting):
• All members of the development team come prepared with the updates for the meeting.
• The meeting starts precisely on time even if some development team members are missing.
• The meeting should happen at the same location and time every day and it lasts 15 minutes.
During the meeting, each team member answers three questions:
1.What did I do yesterday that helped the Development Team meet the Sprint Goal?
2.What will I do today to help the Development Team meet the Sprint Goal?
3.Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
source: Wikipedia

13.
(USER) STORIES
In Scrum, work is expressed in the backlog as user stories. Team
members are encouraged to think of their work from the perspective of
who will use it (e.g. “text message”, “debug GPS tracking system”).
A good rule of thumb is that anything that requires more than one step to
complete or requires more than one person to complete, then it's a good
candidate to be a story.
This model of the user story is most often written like this:
As a [end user role], I want [the desire] so that [the rationale]
source: Wikipedia

14.
PRACTICES

15.
SPRINT PLANNING
How to make sure the team select the right stories that they can
actually deliver that sprint (that deliver value to the company)
source: Jay McGraven at Codeschool

16.
KEY POINTS
➡LOCK REQUIREMENTS DURING SPRINTS
NOT CHANGING STORIES DURING THE SPRINT
➡TIME-BOXING
KEEP THE DURATION OF EACH ITERATION THE SAME
➡ONLY THE TEAM ESTIMATES
THE PEOPLE WHO DO THE WORK SHOULD BE THE ONE
WHO ACTUALLY ESTIMATE THE EFFORT INVOLVED
➡PRODUCT OWNER AVAILABILITY
TO ANSWER TEAM QUESTIONS
source: Jay McGraven at Codeschool

17.
LOCK REQUIREMENTS
➡Changes in mid-sprint jeopardize work investment
‣Planning isn’t free
‣Work toward discarded/delayed features isn’t free (if you
change plans your current work is lost)
➡Increases risk
‣Other features may not get delivered
‣Other features may have defects
During a sprint iteration not changes are made
that affect the sprint call
source: Jay McGraven at Codeschool

18.
TIME-BOXING
➡Short consistent duration
‣reduces miscommunication during the planning process
‣helps to detect problems with features sooner (i.e. extra
dialog is not needed)
‣helps to detect problems with development method
sooner (e.g. extra tests, or integration servers in place)
‣allows known end date to lend sense of focus and
urgency
‣prevents (extra) feature creep without proper oversight
All iterations should be the same duration
(usually 2-4 weeks)
source: Jay McGraven at Codeschool

19.
TEAM ESTIMATES
➡They have unique insight on obstacles
‣Especially hard to test?
➡Estimates can reveal incorrect assumptions about
requirements
Only people actually doing the work should
estimate effort
source: Jay McGraven at Codeschool

20.
PRODUCT OWNER
AVAILABILITY
➡has unique domain knowledge
‣worked more with the customer in the past free
‣has been a customer itself at some point
➡needed for clarification during estimation
➡at first, stories will be missing details needed to
implement
‣it has to be available for developer clarifications
➡it’s a full time job
‣if neglected, quality is gonna suffers
Know what features need to be implemented
and in what order
source: Jay McGraven at Codeschool

21.
EXTENDING SPRINT OR
FAILING A STORY?
LET THE STORY FAIL
then just picked up and finished up and go
for the next sprint
Doing otherwise misses an opportunity to inquire into
•what went wrong
•how the process can be improved in the future
source: Jay McGraven at Codeschool

22.
USER FEEDBACK
How to make sure it’s not getting lost in the shuffle
source: Jay McGraven at Codeschool

23.
KEY POINTS
➡GET THEM…
without them the team is flying blind
➡…QUICKLY
one of the best reason to move away from waterfall stall
development
➡MAKE IT EASY
otherwise the users may not speak up (they’re busy after all)
source: Jay McGraven at Codeschool

24.
DEMO EVERY SPRINT
➡Alternative is progress reports, that can be misinterpreted
➡Stakeholders need to see product early
‣They don’t have time to read detailed specs
‣Working software offers a clearer picture
‣A clearer picture allows better planning
‣Better planning means less wasted work!
source: Jay McGraven at Codeschool

25.
MAKE FEEDBACK EASY
➡You need feedback from users too
➡But they’re busy people
‣Make ti difficult, and issues will go unreported
‣Make it easy, and their feedback will boost product quality
➡Don’t ignore what you get (read it in standup)
‣Good feedback boosts morale
‣Bad feedback is a chance to improve
source: Jay McGraven at Codeschool

26.
TESTING
How to ensure that technical death is not creeping into
the project
source: Jay McGraven at Codeschool

27.
KEY POINTS
➡TEST AT DEVELOPMENT TIME
adding features to a broken codebase is a recipe for disaster
➡SHARED DEFINITION OF “DONE”
can help assure that the proper tests take place
source: Jay McGraven at Codeschool

28.
TEST AT DEV TIME
If tests are not done during development time:
➡separate test phase discovers bugs AFTER they’re easy to fix
➡incurs dangerous technical debt
‣lowered velocity
‣compounding defects
‣rising support costs
➡if testers are at capacity, developers should help
‣if testing is a pain, developers will automate more of it!
Throwing code over the wall and waiting for
defects its a bad idea
source: Jay McGraven at Codeschool

29.
SHARED DEF OF “DONE”
When a story is “done” it means it’s in a RELEASABLE state.
A common shared definition allows to:
➡avoids miscommunication
➡keeps testing from slipping through cracks
‣automated unit test
‣automated integration test
‣manual testing
The team definition of “done” is a list of all the tasks that must
be completed before feature can be considered complete
source: Jay McGraven at Codeschool

30.
AGILE SALES

31.
KEY POINTS
➡SET GOALS
(e.g. budget or number of paying customers objectives)
➡SET SPRINT CYCLE
monthly goals per person, weekly reports
➡DEFINE TOOLS
identify the instruments used by the single sales pro
➡REPORT
maintain the team updated with sales progressions

32.
TRELLO

33.
OUR SCENARIO
Each Trello card is a story containing different lists of specific
activities assigned to team members

34.
HOW WE USE LISTS
Each list is a different step of the scrum process
‣ICELOG: the collector of ideas, suggestions, desiderata
that need brainstorming and approval
‣BACKLOG: features, bugs or improvements chosen
and prioritized by the product owner
‣TODO: stories that need to be completed in the current
sprint
‣DOING: stories in progress in the current sprint
‣DONE: missions accomplished :)

35.
HOW WE USE CARDS
Each card is a story.
The order of the card determines the priority.
‣MEMBERS: all the people involved in the
completion of the story (designer, developer, …)
‣CHECKLISTS: each member has its own
checklist with the tasks that need to be completed
‣LABEL: the overall complexity / estimated time of
the specific story