Scrum for a team that have appled Scrum
•Download as PPTX, PDF•
2 likes•1,004 views
I make this presentation for a project with 5 team member, they've decided to applied Scrum for some Sprint, but they want to strengthen their Scrum skills
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Scrum for a team that have appled Scrum
Similar to Scrum for a team that have appled Scrum (20)
Recently uploaded
Recently uploaded (20)
Scrum for a team that have appled Scrum
- 2. 1 common understanding of some Scrum building blocks
- 3. 2 What is core values of Scrum?
- 4. “Scrum is a framework for developing complex products and systems. It is grounded in empirical process control theory. Scrum employs an iterative, incremental approach to optimize predictability and control risks.” --Ken Schewaber-- Complex product Iterative, incremental approach Scrum framework Empirical process control theory
- 5. Complex product Iterative, incremental approach Scrum framework Empirical process control theory
- 6. Agenda Iterative, incremental approach Empirical process control theory Meetings: Daily, S.Review, Retrospective,… Product backlog – Product Grooming … … … …
- 9. Roles Scrum Master Product Owner Scrum Team Events Sprint Sprint Planning Daily Scrum Sprint Review Sprint Retrospective Sprint Grooming Artifacts Product Backlog Sprint Backlog Increment Time- box
- 10. Events Time-boxed (maximum time) Sprint 4 weeks Sprint planning 8 hours Daily meeting 15 min (fixed) Sprint Review 4 hours Sprint Retrospective 3 hours Grooming 16 hours Event time is proportional to Sprint time No need for meetings not defined in Scrum Limit overhead for communication: < 20%
- 11. When does a sprint end ?
- 12. • Includes: all items to be made – Features, functions, requirements – Enhancements – Fixes • Important properties – Description – Order – Estimate
- 13. “Asa student, I want to view my grades online so that I do have to travel all the way long to school to know it ” INVEST I – Independent N – Negotiable V – Valuable E – Estimable S – Small T – Testable From http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
- 14. Product backlog • Single source of requirements • A copy of the truth Product Owner Internal Stakehold er External Stakeholder Scrum Master Development Team Product Backlog
- 15. • Notes: – Bugs from dev team testing is within sprint backlog – Bugs from ProductOwner/Users are in the Product Backlog
- 17. Backlog refinement - Grooming • Includes: – Filling the Product Backlog – Prioritizing PBI’s – Adding acceptance criteria – Splitting up large items • Less than 10% of sprint time
- 19. Estimation
- 20. Estimation not individuals Work is assigned to an entire team … … not individuals
- 21. Estimation Not measure in time, but Effort
- 22. Planning poker
- 25. Definition of Done DoD is a checklist of valuable activities required to produce software • Unit tests passs and coverage met standard (85%) • Code is reviewed (or pair programmed) • Code standards are met • Continues integration implemented (auto build, deployment and testing) • Code is refactored • Non-functinoal tests pass (scalability, reliability, security, etc.) • Document is completed
- 27. Spring Planning Meeting Sprint Planning Meeting Product Backlog Team Capabilities Business Conditions Technology Current Product Sprint Backlog Sprint Goal
- 28. Parts of Sprint Planning Meeting • 1st Part: What will be done? – Select Product Backlog items – Determining the Sprint Goal. – Participants: Product Owner, Scrum Master, Scrum Team • 2nd Part: How will chosen work get done? – Participants: Scrum Master, Scrum Team – Creating Sprint Backlog
- 30. Scrum Team • Self-organize • Cross-function
- 31. Summary Part 1 Iterative, increment al approach Empirical process control theory Time-box events Product backlog Product Grooming Estimation : 2 principles, planning poker Definition of DONE, technical debt Scrum team: cross-.., self-.. …
- 32. Empirical = knowledge comes from experience and making decisions based on what is known
- 33. Empirical = Inspect & Adjust Exp: Temperature control system for a room – What input parameter do you need? Empirical
- 34. How does “Empirical ” expose in Scrum ?
- 35. 3 Scrum pillars - Transparent
- 36. Transparent = Vision You act on what you perceive
- 37. Transparent in Scrum How does Scrum create transparency?
- 38. “Scrum is a framework for developing complex products and systems. It is grounded in empirical process control theory. Scrum employs an iterative, incremental approach to optimize predictability and control risks.” --Ken Schewaber--
- 39. Summary Iterative, incremental approach Empirical process control theory Time-box events Product backlog Product Grooming Estimation : 2 principles, planning poker Definition of DONE, technical debt Scrum team: cross-.., self-.. Empirical = inspect and adapt Transparent is all Scrum
- 40. • http://www.scrum.org • http://scrumtrainingseries.com/ • http://qualityswdev.com/2010/02/24/how- transparent-is-scrum/ • … (and a lot more)
- 41. &Thank you
Editor's Notes
- To define the GOALIn the context that we have decided to use Scrum for the project. So I do not focus us Why should we select Scrum? = How effective it is in practical? …But I define 2 goalsFirst, …I will elaborate, give details, properties, rules on some types of meeting that we often conduct during the 3 sprints. As well for Roles that often call others: Scrum mater, scrum team, or product ownerThen we build a common understanding of requirements for each of those component.
- Second part is my favorite.I think all the defined elements such as daily meeting, product owners, product backlog, … are just the output behavior.The reasons, philosophy behind them is more important. They will direct us to properly apply, or even when we want to customize, we still keep the core, we still obtain all the built-in value, benefit of Scrum.
- This is a great diagram1. The project is initiated by some stakeholder demanding for a system/product to solve their problems.The idea is rough, without very detailed and in pure business term. 2.They tell their idea to PO. PO will collect all SH’s idea and organize them into a list. Until the list is detailed, fine-grained enough, PO give it to Scrum Team. Scrum team will start many circle of Sprint to process them.3. Each sprint, some item from product backlog is chosen to be implemented, then being broken down into a list of more detailed, actionable task list, called Sprint backlog. Each sprint should be within1-4 weeks. Each working day in sprint will start with a 15-minute daily meeting
- http://agilebench.com/blog/the-product-backlog-for-agile-teamsIt’s pretty common to have items in the form of:user stories – representing new functionality; and bugs – representing work to address a defect.Over time you may be a bit more sophisticated an add in:chores – representing work that must be done, but provide no direct business valueepics – representing big user stories. Originally defined as too big to fit in an iteration (the equivalent of a Scrum sprint).prototypes (a form of risk mitigation) – representing proof of concepts that help provide information for decision making around whether some functionality may be valuable.
- http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/And customer-oriented
- http://osnabrugge.wordpress.com/2013/04/07/tfs-as-perfect-tool-for-scrum-part-2-product-backlog-grooming/
- http://osnabrugge.wordpress.com/2013/04/07/tfs-as-perfect-tool-for-scrum-part-2-product-backlog-grooming/
- Team look forward pbis in the futurePurpose: understand the description, do daft estimation. These estimation becomes input for PO to reprioritize pbis Thanks to this grooming, all pbis are well understood before Sprint PlanningParticipants: PO, ScrumMaster, Dev team.
- Game rule:Whole team, one featureRaise result at the same timeIf the result is not similar, each member explain their reasonThe important thing is that the team shares an understanding of the scale it is uses, so that every member of the team is comfortable with the scale’s values.
- DoD is a checklist of valuable activities required to produce softwareDoD is not static but is informed by reality.
- Engaged Teams Outperform Manipulated TeamsThe natural human tendency to be accountable to a peer group contradicts years of habit for workers. Allowing a team to become self-propelled, rather than manipulated through extrinsic punishments and rewards, contradicts years of habit for managers.Heterogeneous teams outperform homogeneous teams at complex work. They also experience more conflict.Disagreements are normal and healthy on an engaged team; team performance will be determined by how well the team handles these conflicts.Bad apple theory suggests that a single negative individual (“withholding effort from the group, expressing negative affect, or violating important interpersonal norms”) can disproportionately reduce the performance of an entire group. Such individuals are rare, but their impact is magnified by a team’s reluctance to remove them. This can be partly mitigated by giving teams greater influence over who joins them
- Any information you perceived reflect your action, decision. To a developer, what influences:Your tasks, your technicalFuture of product, relevant feature, how your colleague solve his problem, what is your partner obstacles, how is the reaction of customer, ….
- http://qualityswdev.com/2010/02/24/how-transparent-is-scrum/How does Scrum create transparency?A visual (physical) task board is a great tool to raise the team’s visibility of the status of the current Sprint. For me the instant status report for manager type people is a mere side effect. Much more important is the constant feedback for the team – to be aware of the progress within the Sprint. Only with this knowledge can the team be truly self-organizing. This is why I am usually against all these software tools that try to replace a physical task board. Yes, there is a slight overhead to produce index cards and print out the burndown chart, but in my opinion it is minor in comparison to the raised level of transparency. Advocates of Kanban say that the typical Scrum task board with its columns for Backlog, In Progress and Done is not transparent enough. The column In Progress is a black box, hiding states like Analysis or Development. What is the right granularity for your team depends on your context, like the complexity of your development process, team size and others. My advice is to try keeping it as simple as possible without sacrificing transparency.Early feedback is essential to make sure you are doing the right thing and that you are doing it right. It enables the team to discover and correct any errors and misconceptions as soon as possible. Feedback cycles can be applied at every level of development: pair programming, unit tests, acceptance tests, Daily Scrums, Sprints and releases. The time frames of these cycles range from seconds to months and the feedback is coming from different sources: your colleagues, automated tests, the Product Owner and most importantly the users of your product.Future work seems to be predictable. This is achieved by the Product Backlog, which can be examined by anyone anytime. This creates a sense of predictability during the project. Even though most team members barely ever look at it, its existence creates the illusion of anticipation of where the project is heading.Cross-functional teams work together on a common task. In an ideal (software development) world there is no them only an us. More often than not there is a bit of rivalry and tension when developers, testers and DBAs are in separate teams. This is because they don’t understand each others pain points, caused by a lack of communication and transparency between teams. In big organizations they might not even sit in the same office or know each other personally. People tend to be so much more understanding and forgiving when they communicate face to face rather than via email. By putting all needed specialists within the same team, Scrum enables communication between them and makes their needs transparent to each other.