Introduction to Scrum PDF

Agenda Introduction to Scrum Scrum Methodology Is a holistic approach for use by a cross-functional team...

Agenda Introduction to Scrum Scrum Methodology Is a holistic approach for use by a cross-functional team collaborating to develop a new product. Defines product features as deliverables and prioritizes Why Study Scrum Team them by their perceived highest value to the customer. Scrum Intro Agile Rights Agile Agile Rights Re-evaluates priorities after each iteration (sprint) to produce fully functional features. Key Scrum Roles and Responsibilities Key Scrum Roles and Responsibilities Product Nika Acts on behalf of customers to represent Owner their interests. Represents various interests and needs in the project. Development Is a team of 5-9 people with cross- Stakeholders are typically functional skill sets is responsible for Stakeholders from outside the Team delivering the product. immediate Agile team, such as customers, Alphonso Facilitates scrum process and resolves business partners, or Scrum Master impediments at the team and organization company executives. level by acting as a buffer between the team and outside interference.  Agile Rights/ Rules of Agile Agile Rights/ Rules of Agile 1. To be treated with respect 6. To have commitments made to you honored, and in the 2. To have decisions made in a timely manner case where this is not possible to have alternatives 3. To produce and receive quality work at all times based on negotiated with you in a timely manner agreed-to project standards and principles 7. To determine how your resources will be invested (how 4. To estimate the activities you are actively involved with, and funds will be spent, what tasks you choose to work on) to have those estimates respected by others 8. To be given the opportunity to gain the knowledge and 5. To be provided adequate resources, including but not skills pertinent to making the project a success limited to time and money, to do the job that’s been asked of you The Rights of Everyone The Responsibilities of Everyone 9. To work in a “safe environment” where people have the 1. To produce a solution that best meets your stakeholder opportunity to make mistakes, and better yet to have those needs with the degree of resources they are willing to invest mistakes recognized as valuable learning experiences 2. To optimize your organization’s resources invested in your 10.To be commended, nurtured, and supported team / project 11.To be provided good faith information in a timely manner 3. To be willing to collaborate extensively within your team as 12.To own your organization’s software processes, following well as working with others outside your chosen specialties and actively improving these processes when needed 4. To share all information, including “work in progress” 5. To coach others in your skills and experiences The Responsibilities of Everyone Sources 6. To validate your work to the best of your ability, as early as Ambler; Lines, Disciplined Agile Delivery possible, working with others as needed to do so 7. To actively expand your knowledge and skillset and apply these skills in areas outside your specialty when needed 8. To attend coordination meetings in person if on-site or through other means if not co-located 9. To proactively look for ways to improve your or your team’s performance throughout the project 10.To avoid accepting work currently outside the current iteration without agreement by the team 18  Agenda Scrum Planning Processes Product High-level requirements & rough roadmap time frame Scrum Sprint Release Timetable for release of working Process Timing planning software Requirements to be completed Sprint planning during the sprint Daily planning – What the team will work on today (daily standup) Scrum Planning Processes SCRUM Sprint timing Product Roadmap 8 weeks between now and the release date Communicates the “why” Might cover a year or more for the project. Often shared with executive stakeholders Serves as a high-level, visual summary Release Plan How many sprints should we have? Details the “what” Spans only a few months Typically, an internal working document for the product and development teams Takes the strategy into an actionable plan built on specific SCRUM Sprint timing Longer Sprints (3-4 weeks) 8 Week Project How many sprints should we have?  Longer Sprints (3-4 weeks) Shorter Sprints (1-2 weeks) “Dark Work” is any work that wasn’t intended to be done during the Sprint that is picked up and done without being surfaced to the team and placed on the board SCRUM Sprint timing Agenda 8 weeks between now and the release date for the project. Options 8 weeklong sprints 4 weeklong sprints and 4 week contingency Stakeholders The Product The Scrum The Secondary/ Development Other Team Owner Master 4, 2 weeklong sprints Team Members 1, 8 weeklong sprint Stakeholders The Product Owner Anyone who is materially impacted by the outcome of the Vision Owner: Brianna solution Define and communicate the product vision and strategy to the team. Ensure that the team understands the bigger picture of End user (customer) what they're building. Manager of users Senior management Requirements Management: candice Examples Operations / maintenance team Create, maintain, and prioritize the Product Backlog. Support / help desk Auditors Elaborate product backlog items, ensuring requirements Program / portfolio management are clear and well-understood. Developers on other projects Ensure that user stories and acceptance criteria are Architects, tools managers defined.  The Product Owner The Product Owner Stakeholder Management: Brianna Accept or reject the work results at the end of each sprint. Act as the primary liaison between stakeholders and the Create, maintain, and prioritize the Product Backlog. development team. Represents the Client or Customer in the Agile team Gather feedback and requirements from stakeholders Elaborate product backlog items, ensuring requirements are and users. clear and well-understood. Keep stakeholders informed about product progress and Ensure that user stories and acceptance criteria are defined releases. Act as the primary liaison between stakeholders and the Decision Maker: development team. Make tough decisions regarding prioritization based on Decide on release dates and content. business value, technical considerations, and stakeholder needs. Decide on release dates and content. Accept or reject the work results at the end of each sprint. The Product Owner The Product Owner Responsibility A Good Product Owner … Responsibility A Good Product Owner … Develops project strategy and Envisions the completed product Understands which product features can deliver Is responsible for budget and direction Understands company strategy the best ROI profitability Has worked with similar products before Manages budgets effectively Provides product expertise Understands final user needs Decides on release dates Understands business needs regarding schedule Creates a solid customer input and feedback Works well with developers Understands customer and Works with the development channel Describes product features effectively other stakeholder needs team Works well with business stakeholders Is available for questions and clarifications daily Remains flexible Understands requirements and ensures that Accepts or rejects work Turns stakeholder feedback into valuable completed features work correctly Manages and prioritizes features product requirements Is practical when prioritizing valuable features, high-risk features, and system improvements on behalf of the enterprise Challenges for the Product Owner The Scrum Master Product owners often “go native” Facilitator: The product owner can become the bottleneck Organize and facilitate Scrum ceremonies The product owner should not be the scrum master daily stand-ups, sprint planning, sprint reviews, and retrospectives. Product owners rarely represent the entire stakeholder Servant Leader: community Serve the team by addressing and removing Product owners must be skilled negotiators impediments. Support the Product Owner in refining and maintaining the product backlog. Shield for the Team: Protect the team from external interruptions and distractions. Ensure that the team can focus on the sprint goals without disturbances.  The Scrum Master The Scrum Master Continuous Improvement Advocate: Responsibility A Good Scrum Master … Acts as a process coach, Facilitate sprint retrospectives to identify areas of helping the team follow scrum Is an expert on scrum processes improvement. Is passionate about agile techniques practices and values Implement and promote best practices to improve team Has organizational clout and can resolve efficiency. problems quickly Removes roadblocks and Is articulate, diplomatic, and professional Process Enforcer: prevents disruptions Is a good communicator and a good listener Ensure that the team adheres to Scrum practices and Is firm about the development team’s need to rules. focus only on the project and the current sprint Track and report Scrum metrics like velocity and sprint progress. Team Empowerment: Encourage team decision-making. Promote team ownership of products and processes. The Scrum Master Challenges for the Scrum Master Responsibility A Good Scrum Master … The scrum master should not be product owner (why?) Fosters close cooperation Looks at the needs of the project as a whole between stakeholders and the Avoids cliques and helps break down group Smart team members “promoted” to the scrum master role team silos without the required skill set Understands techniques to help groups reach Facilitates consensus building agreements Regression to “command and control” traditional project Does not need or want to be the boss or “in management charge” The scrum master isn’t fully utilized Ensures that all team members of the Is a servant-leader development team have the information they need to do the job, use the tools, and track progress Truly desires to help the team succeed The Development Team The Development Team Self-Organization: Product Backlog Implementation: Organize themselves to complete work without being Select and pull product backlog items into the sprint directed by outside parties. during sprint planning. Decide as a team how to best accomplish their tasks. Break down product backlog items into tasks and Cross-Functionality: manage them throughout the sprint. Possess all the skills necessary to create a product Estimation: increment. Estimate the effort required for product backlog items. Collaborate across different roles and specialties. Update estimates as more is learned about the product Deliver Incrementally: and its requirements. Produce a potentially shippable product increment at the end of each sprint. Ensure the increment meets the "Definition of Done" criteria. Product Backlog Implementation:  The Development Team Challenges for the Team Member Responsibility A Good Agile Team Member … Overspecialization Enjoys creating products Creates the product Organizational resistance to cross-functional work Is skilled in at least one of the jobs necessary Is self-organizing and self- Has initiative and can work independently Struggling to collaborate effectively Understand how to work through barriers to managing achieve goals Has curiosity Willingly contributes outside their area of Is cross-functional expertise Enjoys learning new skills Enthusiastically shares knowledge Is dedicated to the project and Is part of an organization that understands the available for co-location benefits of focused, co-located teams Secondary Team Members Agenda - Architecture owner Architecture owner: guides the creation and evolution of the architecture of the solution that the team is working on Domain experts, specialists, technical experts Independent testers User Stories The Product Release Sprint Backlog Planning Planning User Stories The Product Backlog A simple description of a product requirement: Product Backlog: A comprehensive list of all user stories developed for the product Title User stories are typically prioritized by the product As a owner based on value to the customer. I want to So that User stories may also include a rough estimate of the (Optional) When I , this happens effort required Note that the list of user stories are likely to change throughout an agile project (Why?)  Release Planning How Many Releases? A release is a group of usable features that are released to production (to customers) It does not have to include all of the planned features, but it should include “minimal marketable features” The incremental cost to The incremental value of a The cost of managing deploy a release release multiple versions in the The features and the timing field of the release are typically determined by the product owner, with inputs from key stakeholders, customers, and the development team Sprint Planning Sprint Planning At the beginning of A sprint is a period of time (sometimes called an each sprint, the scrum iteration) in which the development team creates a team reviews the specific group of product capabilities from start to finish product backlog and decides which user At the end of each sprint, the product is working and stories to include in the ready to demonstrate to stakeholders sprint Typically 2-4 weeks in length These user stories become the sprint Sprints are time-boxed: they must end on-time and backlog cannot be delayed Agenda Organizing the Scrum Work Space Dedicated space Large table The most effective Projector Remote/ Scrum teams have their own Food and toys Distributed work area Workspace Moveable desks, chairs teams Whiteboards, corkboards, empty wall space Supplies: whiteboard markers, sticky notes (different colors), index cards, flip charts, tape, stick pins, string  Flexible Arrangements Work Area Examples Moveable desks, chairs, whiteboards Wireless connections Cubicles or Open Work Area? Scrum task boards Cubicles Open Work Area Privacy Can accommodate more Personal space people Harder to collaborate Encourages collaboration Harder to update Noisy status no privacy Low-tech Easy to update and read Abnormal conditions immediately visible Enables quick problem solving Co-Location Communication & Co-Location Co-location enables: Communicating face-to-face Using simple, low-tech tools for communication Real-time questions and clarifications Being aware of what others are working on Asking for help and supporting others  What About Distributed Teams? Communication with Dislocated Teams The greater the level of geographic distribution, the greater the need for technology More time required for planning Be prepared for the need to have people travel between Teleconferencing and videoconferencing locations Maximize the independence of the sub-teams (including outsourced teams) Use videoconferencing to simulate F2F communication Arrange in-person meetings for all team members, at least once at the beginning of the project Use on-line collaboration tools (virtual whiteboard) Include team members’ pictures Be sensitive to time differences Ask for clarification frequently Be aware of language and cultural differences