Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Scrum with Asana

3.518 visualizaciones

Publicado el

Introduction to Scrum and How to Apply It with Asana, heavily based on Scrum Primer (http://scrumprimer.org/)

Publicado en: Ingeniería
  • Sé el primero en comentar

Scrum with Asana

  1. 1. Scrum with Asana an agile project management and software development process James G. Kim Strategic Planning Director of LiST Inc. JGKim@LiSTInc.kr April 17th, 2015
  2. 2. Agile Manifesto 2 In February 2001, seventeen software developers, including Kent Beck, Ward Cunningham, and Martin Fowler, met at the Snowbird ski resort, and published the Manifesto for Agile Software Development: We are uncovering better ways of developing software by doing it and helping others do it.
 Through this work we have come to value: • Individuals and Interactions over Processes and Tools • Working Software over Comprehensive Documentation • Customer Collaboration over Contract Negotiation • Responding to Change over Following a Plan That is, while there is value in the items on the right, we value the items on the left more. Derived from AgileManifesto.org
  3. 3. Project Vision Drives the Features 3 Waterfall Agile Contraints Estimates Features Cost Schedule Plan Driven Features Cost Schedule Value - Vision Driven The Plan Creates
 Cost/Schedule Estimates. The Vision Creates
 Feature Estimates. Derived from Arrielle Mali’s slides
  4. 4. Pull Systems 4Derived from Arrielle Mali’s slides CapacityInput ? Push systems overwhelm capacity, creating turbulence, waste, and delay. Input Capacity Pull systems have a steady flow that provides predictability.
  5. 5. Agile Principles 5 The Agile Manifesto is based on 12 principles: • Customer satisfaction by rapid delivery of useful software • Welcome changing requirements, even late in development • Working software is delivered frequently (weeks rather than months) • Close, daily cooperation between business people and developers • Projects are built around motivated individuals, who should be trusted • Face-to-face conversation is the best form of communication (co-location) • Working software is the principal measure of progress • Sustainable development, able to maintain a constant pace • Continuous attention to technical excellence and good design • Simplicity — the art of maximizing the amount of work not done — is essential • Self-organizing teams • Regular adaptation to changing circumstance Derived from AgileManifesto.org
  6. 6. “Rugby”Approach 6 The holistic or “rugby” approach has been defined, as the whole process is performed by one cross-functional team across multiple overlapping phases, where the team “tries to go the distance as a unit, passing the ball back and forth” in 1986 by Hirotaka Takeuchi and Ikujiro Nonaka in The New New Product Development Game. Derived from The New New Product Development Game
  7. 7. Moving the“Scrum”Downfield 7 From interviews with organization members from the CEO to young engineers, we learned that leading companies show six characteristics in managing their new product development processes: • Built-in Instability • Self-organizing Project Teams • Overlapping Development Phases • “Multilearning” • Subtle Control • Organizational Transfer of Learning These characteristics are like pieces of a jigsaw puzzle. Each element, by itself, does not bring about speed and flexibility. But taken as a whole, the characteristics can produce a powerful new set of dynamics that will make a difference. Derived from The New New Product Development Game
  8. 8. Scrum Methodology 8Derived from The Scrum Primer In the early 1990s, Ken Schwaber and Jeff Sutherland developed what would become “Scrum” at their respective companies, and in 1995, they jointly presented a paper describing the Scrum methodology at the Business Object Design and Implementation Workshop held as part of OOPSLA ’95.
  9. 9. Scrum Roles 9Derived from The Scrum Primer In Scrum, there are three roles: Product Owner, Team (also called Development Team), and Scrum Master. Together these are known as the Scrum Team.
  10. 10. Scrum Roles: Product Owner & Team 10 The Product Owner represents the stakeholders, and is the voice of the customer. He or she is responsible for maximizing return on investment (ROI) by identifying product features (typically user stories), translating these into a prioritized list (i.e., Product Backlog), deciding which should be at the top of the list for the next Sprint, and continually re-prioritizing and refining the list. The Scrum Team has one and only one Product Owner, and while he or she may also be a member of the Team, this role should not be combined with that of the Scrum Master. Derived from The Scrum Primer The Team (also called Development Team) is responsible for delivering potentially shippable increments (PSIs) of product at the end of each Sprint (the Sprint Goal). The Team in Scrum is “cross-functional” and it is “self-organizing” (self-managing), with a very high degree of autonomy and accountability. The Team decides how many items (from the Product Backlog) to build in a Sprint by adding them to the Sprint Backlog, and how best to accomplish that goal. Since each member of the Team is just a team member, the Team is not only cross-functional but also demonstrates multi-learning.
  11. 11. Scrum Roles: Scrum Master 11 The Scrum Master helps the product group learn and apply Scrum to achieve business value. The Scrum Master does whatever is in their power to help the Team, Product Owner, and organization be successful. The Scrum Master is not the manager of the Team members, nor are they a project manager, team lead, or team representative. Instead, the Scrum Master serves the Team; he or she helps to remove impediments, protects the Team from outside interference, and helps the Team to adopt modern development practices. He or she educates, coaches, and guides the Product Owner, Team, and the rest of the organization in the skillful use of Scrum. Derived from The Scrum Primer
  12. 12. Asana: Teamwork without Email 12 Asana is a Web-based solution for the effective collaboration of teams. Main user focus is to plan and manage projects and tasks online without the use of email. The Asana workflow for Scrum: • Each team gets a “workspace” for each project, • Workspaces contain ”projects” for lists, and • Projects contain ”tasks” for items. In each item, users can add notes, comments, attachments, and tags. Users can follow lists and items, and when the state of a list or item changes, followers get updates about the changes in the inboxes.
  13. 13. Product Backlog 13 The Product Backlog is a prioritized list of customer-centric features desired in the product. It exists (and evolves) over the lifetime of the product. Derived from The Scrum Primer The Product Backlog includes a variety of items: • New Customer Features
 (e.g.,“enable all users to place book in shopping cart”) • Major Engineering Improvement Goals
 (e.g.,“rewrite the system from C++ to Java”) • Improvement Goals
 (e.g.,“speed up our tests”) • Research Work
 (e.g.,“investigate solutions for speeding up credit card validation”) • Known Defects, if there are only a few problems
 (A system with many defects usually has a separate defect tracking list.) The Product Backlog Items (PBIs) are ordered by the Product Owner based on considerations like risk, business value, dependencies, date needed, etc. The Product Backlog exists (and evolves) over the lifetime of the product; it is the product roadmap (Figure 2 and Figure 3). At any point, the Product Backlog is the single, definitive view of “everything that could be done by the Team ever, in order of priority”. Only a single Product Backlog exists for a product; this means the Product Owner is required to make prioritization decisions across the entire spectrum, representing the interests of stakeholders (including the Team). Figure 2. The Product Backlog Figure 3. Visual Management: Product Backlog items on the wall The Product Backlog includes a variety of items, primarily new customer features (“enable all users to place book in shopping cart”), but also major engineering improvement goals (e.g., “rewrite the system from C++ to Java”), improvement goals (e.g. “speed up our tests”), research work (“investigate solutions for speeding up credit card validation”), and, possibly, known defects (“diagnose and fix the order processing script errors”) if there are only a few problems. (A system with many defects usually has a separate defect tracking system.) Product Backlog items are articulated in any way that is clear and sustainable. Contrary to popular misunderstanding, the Product Backlog does not contain “user stories”; it simply contains items. Those items can be expressed as user stories, use cases, or any other requirements approach that the group finds useful. But whatever the approach, most items should focus on delivering value to customers. A good Product Backlog is DEEP… 6
  14. 14. Product Backlog: DEEP 14 A good Product Backlog is: • Detailed appropriately: The top priority items are more fine-grained and detailed than the lower priority items, since the former will be worked on sooner than the later. • Estimated: The items for the current release need to have estimates, and furthermore should be considered for re-estimation each Sprint as everyone learns and new information arises. • Emergent: In response to learning and variability, the Product Backlog is regularly refined. Each Sprint, items may be added, removed, modified, split, and changed in priority. • Prioritized: The items at the top of the Product Backlog are prioritized or ordered in a 1-N order. Derived from The Scrum Primer
  15. 15. Product Backlog in Asana 15
  16. 16. User Stories 16 Product Backlog Items are articulated in any way that is clear and sustainable. Items can be expressed as User Stories, Use Cases, or any other requirements approach that the group finds useful. User Stories are written by or for business users or customers as a primary way to influence the functionality of the system being developed. User Stories may also be written by developers to express non-functional requirements (security, performance, quality, etc.), though primarily it is the task of the Product Owner to ensure User Stories are captured. As a <role>, I want <goal/desire> (so that <benefit>). As a purchaser, I want to search for generic equivalents of brand named items so that I can save money. Derived from Wikipedia
  17. 17. User Stories: INVEST 17 INVEST Criteria for User Stories: • Independent: The User Story should be self-contained, in a way that there is no inherent dependency on another User Story. • Negotiable: User Stories, up until they are part of an iteration (i.e., Sprint), can always be changed and rewritten. • Valuable: A User Story must deliver value to the end user. • Estimable: You must always be able to estimate the size of a User Story. • Small Sized: User Stories should not be bigger than one Sprint. • Testable: The User Story or its related description must provide the necessary information to make test development possible. Derived from Wikipedia
  18. 18. User Stories in Asana 18
  19. 19. Product Backlog Refinement 19 Product Backlog Refinement is the ongoing process of the whole Scrum Team’s refining (or“grooming”) the Product Backlog to support future Sprints. The Product Backlog Refinement takes no more than 10% of the capacity of the Team for the Sprint. For example, in a two-week Sprint, perhaps one day is spent on refinement. • Detailed Requirement Analysis • Splitting Large Items into Smaller Ones • Estimation of New Items • Re-estimation of Existing Items Derived from The Scrum Primer
  20. 20. Priorities based on Risk, Effort, and Value 20 Asking the following questions of the different items will start a conversation that will start to determine priorities: • Which items add the most value to the user (or customer)? • Which items post the most business risk? • Which items pose the most technical risk? It’s helpful to rank items along the three questions using a scale. • Fibonacci Scale: 1, 2, 3, 5, 8, …
  21. 21. Sprint Planning 21Derived from The Scrum Primer Sprint Planning is a meeting to prepare for the Sprint, typically divided into two parts (part one is “what” and part two is “how”). Each part is timeboxed to one hour per week of Sprint. • Sprint Planning Part One: The Product Owner and Team review the high-priority items in the Product Backlog that the Product Owner is interested in implementing in this Sprint. The Team and the Product Owner may also devise the Sprint Goal, a summary statement of the Sprint objective. • Sprint Planning Part Two: The Team forecasts the amount of items they can complete by the end of the Sprint, starting at the top of the Product Backlog and working down the list in order. The Team selects the first item on the Product Backlog and work their way down until they are ‘full’. For each item, they create a list of work which consists of either decomposed Product Backlog items into tasks, or simply the Product Backlog item. This list of work to be done during the Sprint is called the Sprint Backlog that details the time it will take to do that work.
  22. 22. Tracking Progress during the Sprint 22 this is the reality of product development. The important thing is that it shows the Team their progress towards their goal, not in terms of how much time was spent in the past (an irrelevant fact in terms of progress), but in terms of how much work remains in the future – what separates the Team from their goal. If the burndown line is not tracking downwards towards completion near the end of the Sprint, then the Team needs to adjust, such as to reduce the scope of the work or to find a way to work more effectively while still maintaining a sustainable pace. While the Sprint Burndown chart can be created and displayed using a spreadsheet, many Teams find it is more effective to show it on paper on a wall in their workspace, with updates in pen; this “low-tech/ high-touch” solution is fast, simple, and often more visible than a computer chart. Figure 6. Daily Updates of Work Remaining on the Sprint Backlog this is the reality of product development. The important thing is that it shows the Team their progress towards their goal, not in terms of how much time was spent in the past (an irrelevant fact in terms of progress), but in terms of how much work remains in the future – what separates the Team from their goal. If the burndown line is not tracking downwards towards completion near the end of the Sprint, then the Team needs to adjust, such as to reduce the scope of the work or to find a way to work more effectively while still maintaining a sustainable pace. While the Sprint Burndown chart can be created and displayed using a spreadsheet, many Teams find it is more effective to show it on paper on a wall in their workspace, with updates in pen; this “low-tech/ high-touch” solution is fast, simple, and often more visible than a computer chart. Figure 6. Daily Updates of Work Remaining on the Sprint Backlog Figure 7. Sprint Burndown Chart 12 Everyday, the Team members update their estimate of the effort remaining to complete their current work in the Sprint Backlog. It is also common for someone to add up the effort remaining for the Team as a whole, and plot it on the Sprint Burndown Chart. Derived from The Scrum Primer
  23. 23. Sprint Backlog in Asana 23
  24. 24. Estimate of Effort in Asana 24
  25. 25. Daily Scrum 25 The Daily Scrum (or stand-up) is a short (15 minutes or less) meeting that happens every workday at an appointed time. It is the Team’s opportunity to synchronize their work and report to each other on obstacles. • Before the Daily Scrum: Each member makes sure that the personal ”Assigned to Me” list in the workspace in Asana is properly reflecting the prioritization for the day and the Team’s involvement in the project. • During the Daily Scrum: One by one, each member of the Team reports three things to the other members of the Team: 1. What has been accomplished since the last meeting? 2. What will be done before the next meeting? 3. What obstacles are in the way? There is little or no in-depth discussion during the Daily Scrum. • After the Daily Scrum: Each member updates the “Assigned to Me” list and any relevant lists in Asana. Derived from The Scrum Primer
  26. 26. Scrum Board in Asana 26 Many Teams have a Sprint Backlog in the form of a wall-sized task board (often called a Scrum Board) where tasks (written on Post-It Notes) migrate during the Sprint across columns labeled“To Do,”“Work in Progress,”and“Done.”
  27. 27. Working with Gitflow Workflow 27 • When starting work on a Backlog Item by the Team: - First, move the Backlog Item from the “To Do” Section to the “Work in Progress” Section in Asana. - Second, start a new Feature or Hotfix with Git. • After finishing work on a Backlog Item by the Team: - First, move the Backlog Item from the “Work in Progress” Section to the “Done” Section in Asana. - Second, finish up a new Feature or Hotfix with Git. • After reviewing work on a Backlog Item by the Product Owner: - Mark the Backlog Item completed in Asana. • At the end of the Sprint: - Make a release with Git. The Gitflow Workflow is Vincent Driessen's strict branching model designed around the project release (i.e., the end of the Sprint).
  28. 28. Sprint Review 28 After the Sprint ends, there is the Sprint Review, where people review the Sprint. • The Sprint Review is an inspect and adapt activity for the product. • For a two-week Sprint it is a maximum length of two hours. • Anyone present is free to ask questions and give input. The review definitely includes using the actual live software that the Team built during the Sprint, but if the focus of the review is only looking at the product rather than having a conversation, there is an imbalance. The“live software”portion of the Sprint Review is not a“presentation”the Team gives — there is no slideware. Derived from The Scrum Primer
  29. 29. Sprint Retrospective 29 The Sprint Retrospective, which follows the Review, involves inspect and adapt regarding the process and environment. It’s an opportunity for the Team to discuss what’s working and what’s not working, and agree on changes to try. • Timeboxed to 45 minutes per week of Sprint. • Team, Scrum Master, and Product Owner (optional) attend. • Sometimes the Scrum Master can act as an effective facilitator. • It’s important to ensure that every Retrospective focuses not only on problems, but also on positives or strengths. Derived from The Scrum Primer
  30. 30. Thank You. 30

×