Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Agile Fundamentals and Best Practices (with Trello)

3,296 views

Published on

A brief summary on fundamentals principles and practices of Scrum framework

Published in: Leadership & Management
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • @Filippo Zanella, Ph.D. Thanks for the quick answer! :)
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Szczecinski thank you for the compliment! The concept is that you only archive the "done list", e.g. calling it "done sprint 3". Instead, failed cards can remain in the "doing" list or you can move it back to the "to do" one. We usually freeze (i.e. archive) the state of the closed sprint, to know what we have accomplished and, yes, to compare it with previous/next sprints. We do not keep track of failures directly.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Hi, thanks for great presentation! So do you archive those "to do", "doing" and "done" lists, and start on the same board for the next sprint ? How do you access and compare history of sprints, do you just use archive view ?
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Agile Fundamentals and Best Practices (with Trello)

  1. 1. Agile Fundamentals and Best Practices Filippo Zanella January 29th, 2015 Sellf s.r.l.
  2. 2. OUTLINES 1. FUNDAMENTALS - WHY AGILE - TEAM - PROCESS 2. PRACTICES - SPRINT PLANNING - USER FEEDBACK - TESTING - SALES & MARKETING 3. TRELLO
  3. 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. 4. FUNDAMENTALS
  5. 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. 6. TEAM
  7. 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. 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. 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. 10. PROCESS
  11. 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. 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. 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. 14. PRACTICES
  15. 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. 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. 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. 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. 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. 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. 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. 22. USER FEEDBACK How to make sure it’s not getting lost in the shuffle source: Jay McGraven at Codeschool
  23. 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. 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. 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. 26. TESTING How to ensure that technical death is not creeping into the project source: Jay McGraven at Codeschool
  27. 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. 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. 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. 30. AGILE SALES
  31. 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. 32. TRELLO
  33. 33. OUR SCENARIO Each Trello card is a story containing different lists of specific activities assigned to team members
  34. 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. 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

×