Agile Scrum Quick Reference Card

443 views

Published on

This simple and crisp quick reference card is for Agile and Scrum basics. It is a simple way to glance through all the concepts and use it as a tool for revision, even before an interview.

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
443
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Agile Scrum Quick Reference Card

  1. 1. Agile SCRUM– Roles, Artifacts, Meetings, Tools, Glossary Quick Reference Cards +9122 4015 5175 +9122 2570 2772 +9122 2857 4960 http://www.techcanvass.com/ Copyrights @ Techcanvass | all rights reserved Owns the Software Scrum Team figures out how to turn the Product Backlog into an increment of functionality within a Sprint. Each team member is jointly responsible for the success of each iteration and of the project as a whole. • Team is cross functional ( Business Analyst, developer tester) • Team consists of 3-12 full time members ( Exceptions : Specific roles DBA) • Self-organizing and self-managing team • Maintains the Sprint Backlog • Conducts the Sprint Review • Technical implementation of User Stories • Delivers a “potentially shippable” product increment at every Sprint Manifesto for Agile Roles - Product Owner (PO) Owns the Product Backlog Product Owner represents the interests of project Stakeholders and is responsible for the final product • Elicitation of product requirements and features • Responsible for prioritizing of requirements • Owns the Product Backlog • Manage the Release Plan • Manage the Return on Investment • Accountable for product success Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan Dynamic prioritized list of requirements • Product backlog is dynamically prioritized list of requirements ordered by Business Value • Requirements can be added by anyone at anytime • PBL can contain bugs and non-functional items • Requirements are broken down into User Stories by Product Owner • Prioritize the requirements based on Business Value Artifacts - Product Backlog (PBL) Owns the Scrum process Scrum Master is responsible for the Scrum process. He ensures everybody plays by the rules. The Scrum Master is not part of the Team. • Manage the Scrum process • Remove impediments for the Team • Facilitate communication • Is a facilitator and not a manager • Shields the team from external interference Roles – Scrum Team 1. Satisfy the customer through early and continuous delivery 2. Welcome changing requirements, even late in development 3. Deliver working software frequently 4. Business people and developers work together daily 5. Build projects around motivated individuals 6. Convey information via face-to-face conversation 7. Working software is the primary measure of progress 8. Maintain a constant pace indefinitely 9. Give continuous attention to technical excellence 10. Simplify: maximize the amount of work not done 11. Teams self-organize 12. Teams retrospect and tune their behaviors Meetings – Sprint Planning To commit the deliverable(s) to the PO PBL prepared prior to meeting. It’s a two part meeting: • PO presents the User Stories • Team selects items committing to complete • Discussion on PBI for clarifications • Creation of Sprint Backlog from PBL • Team solely responsible for deciding how to build • Breakdown of user stories in Tasks to fill the SBL (normally 3 to 4 days of work, than inspect & adapt) • PO available for questions Timebox: 4 hours Owner: Product Owner Participants: Scrum Master, Scrum Team Displays the remaining work • Burndown chart shows the amount of work remaining per Sprint • It is a very useful way of visualizing the correlation between work remaining at any point in time and the progress of the Team(s) • Use a tool e.g. JIRA for auto creation of the Burndown Chart To Inspect and Adapt the progress In this standup meeting the Team daily inspects their progress in relation to the Planning by using the Burndown Chart, and makes adaptation as necessary. • Held every day during a Sprint (same time & place) • Team members report to each other and not to SM • Ask 3 questions during meeting: "What have you done since last daily scrum?" "What will you do before the next daily scrum?" "What obstacles are impeding your work?“ Timebox: 15 minutes Owner: Scrum Master Participants: Team, all interested parties may silently attend To maintain the good, get rid of the bad At the end of a Sprint, the Team evaluates the finished Sprint. • What went well and what can be improved • Capture positive ways as a best practice, identify challenges and develop strategies for improvements. • SM helps team in discovery & not provide answers Timebox: 3 hours Owner: Scrum Master Participants: Team, (Product Owner) To demonstrate the achievements The team present product owner the result on the developed product of the Sprint. Product owner can accept or reject features depending on the agreed acceptance criteria. Timebox: 4 hours Owner: Team Participants: Scrum Master, Product Owner, optionally the PO can invite other Stakeholders Meetings - Daily Scrum Meetings - Sprint Review Artifact - Burndown Chart Visibility + Flexibility = “Scrum” “Done” = Potentially Shippable Scrum requires at the end of each Sprint that the product is production ready. That means the increment is: • Thoroughly tested and stable • Well-structured • Well-written code • User operation of the functionality is documented Artifacts - Potentially Shippable Product List of Tasks to fulfill the Sprint Goal • Sprint Backlog contains all the committed User Stories for the current Sprint broken down into Tasks by the Team • All items on the Sprint Backlog should be developed, tested, documented and integrated in order to fulfill the Sprint Goal. • Estimate Story complexity using Planning Poker Artifacts - Sprint Backlog (SBL) 12 Principles of Agile Development Roles - Scrum Master (SM) Meetings – Retrospective
  2. 2. Agile SCRUM– Roles, Artifacts, Meetings, Tools, Glossary +9122 4015 5175 +9122 2570 2772 +9122 2857 4960 http://www.techcanvass.com/ Copyrights @ Techcanvass | all rights reservedQuick Reference Cards Set of values as the foundation for the team's processes and interactions Commitment towards team and Sprint Goal Focus being focused on the sprint and its goal Openness to highlighting when you have challenges and problems that are stopping you from success Respect helping people to learn the things that you are good at and not judging situations and people Courage to being transparent, but willing to change even if that means accepting that you are wrong Scrum / Task Board • Board containing teams Sprint goals, backlog items, tasks, tasks in progress, "DONE" items and daily Sprint Burndown chart • Scrum meetings best held around task board • Visible to everyone Free online Agile tools: Icescrum , Taiga , Scrumpy, Hansoft, scrumdesk ,YouTrack , JIRA, VersionOne and scrumdo Tools – Scrum Board 5 Scrum Values Inspection Timely checks on the process and artifacts towards Sprint Goal to detect undesirable variances Adaptation Adjusting a process as soon as possible to minimize any further deviation or issues 3 pillars in SCRUM SCRUM uses an empirical approach in order to adapt to the changing requirements of the customer Transparency Viewed in the form of Product Backlog, Task Boards and Burndown charts, Daily Stand-ups, Retrospectives, Sprint Reviews Empirical Process in SCRUM Make SMART Requirements: Simple, Measurable, Achievable, Realistic, Traceable. User Stories A very high level definition of what the customer wants the system to do. Each story is captured as a separate item on the PBL User Story Template: As a <user> I want <function> So that <desired result> INVEST in User Stores: • Independent • Negotiable • Valuable • Estimable • Small • Testable Tasks Make sure a Task is TECH. Time boxed, Everybody (can pick it up), Complete and Human-readable Requirements – User Stories & Tasks Epic: A very large user story that is eventually split up into multiple related user stories Timebox: Fixed time period which cannot be exceeded Scrum: Most widely used agile framework comprising of short iterations, called sprints. Actual work is done within sprints Sprint: Sprint is the scrum term for an iteration Task: A completely broken down form of a user story Spike: A short, time-boxed piece of research, usually technical, on a single story that is intended to provide just enough information that team can estimate the size of story Definition of “Done” (DoD): List of development activities required to consider an increment of functionality as “Done”. Velocity: Rate at which team converts items to “DONE” in a single Sprint. It is usually calculated in Story Points Poker Planning: Consensus based approach for estimating the efforts for a task. Generally involves team members and POs proposing estimation values using poker cards and then finally everyone agreeing to one value Impediment: Anything which slows the team down or prevents someone from working Technical Debt: A consequence of poor engineering practices which make a program difficult to modify. Technical bankruptcy follows: Throw the program away and write a new one Is Scrum agile? Yes. Scrum is agile, but agile is more than Scrum. Scrum signs up to all of the values and principles in the Agile Manifesto and so is one member of the agile family along with eXtreme Programming (XP), Kanban, Lean software development, Crystal, and even hybrids such as Scrumban. Who is responsible for managing the teams? Teams are responsible for managing themselves What is the effort/duration of a task? Tasks should take no longer than 16 hours. If longer then the task should be broken down further Who manages obstacles? Primary responsibility of managing obstacles is on the Scrum Master. However, teams must learn to resolve their own issues. Two of the biggest challenges in Scrum? • Teams not self-managing • Scrum Master managing not leading Agile Process Glossary FAQ Story points are estimates of effort as influenced by the amount of work, complexity, risk and uncertainty • Most popular way of estimation in Agile • Relative sizing technique • Entire team irrespective of specialty has to provide a single estimate and not sum of individual estimates • Usually scored on a scale of 1 to 10 (in order of difficulty) Estimation - Story Point (SP) Technique for Normalizing Story sizing: • Find a small story and assign it one Story Point • Estimate every other story relative to this story • Points to consider while doing relative sizing: Complexity, Knowledge and experience in the domain, technology, Uncertainly, Volume, Repetition and Risk

×