Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in our knowledge base article
Do you really want to delete this prezi?
Neither you, nor the coeditors you shared it with will be able to recover it again.
Make your likes visible on Facebook?
Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.
Agile & Scrum
Transcript of Agile & Scrum
the right, we value the items on the left more. Agile Is Not Rather An excuse to stop producing project documentation. A chance to question the need for the document
and eliminate producing anything that doesn't make
sense, isn't valuable, or isn't useful - regardless of
previous practice. An opportunity to eliminate planning. Planning that does not preclude building your product.
It is lightweight, efficient, and iterative. An open door for scope creep. Flexible and transparent allowing stakeholders to
request changes while taking deliberate tradeoffs
into consideration. A rigid "best practice" subscription. A set of guiding principles with many implementation
options such as XP, Scrum or Kanban. what's this "scrum" stuff? Scrum is an iterative and incremental agile software development method for managing software projects and product or application development. “The ‘relay race’ approach to product development…may conflict with the goals of maximum speed and flexibility. Instead a holistic or ‘rugby’ approach - where a team tries to go the distance as a unit, passing the ball back and forth - may better serve today’s competitive requirements.”
Hirotaka Takeuchi and Ikujiro Nonaka
"The New New Product Development Game"
Harvard Business Review, January 1986 In 1995, Jeff Sutherland and Ken Schwaber jointly presented a paper describing the Scrum methodology at the Business Object Design and Implementation Workshop held as part of OOPSLA ’95 in Austin, Texas, its first public presentation. Schwaber and Sutherland collaborated during the following years to merge the above writings, their experiences, and industry best practices into what is now known as Scrum. Processes & Artifacts Sprint Sprint Planning Meeting A "sprint" is simply a defined time-frame in which a set of development tasks, estimated and agreed upon by the team, are coded, tested and deemed ready for production. Sprints are typically 1-4 weeks in duration. Held by the team at the onset of each sprint in which the team reviews the product backlog, agrees upon which items can be completed during the sprint and moves those items to the sprint backlog. Daily Scrum Held by the team at a consistent time of day, each day throughout the sprint, to answer three questions: what was completed since the last scrum, what will you complete today and are you blocked? Sprint Review & Demo Held at the end of each sprint to provide project stakeholders transparency into work completed as well as a chance to provide immediate feedback that could turn into work during the next sprint. Retrospective Team only meeting to review and discuss the previous sprint. This meeting should focus on the development process and is meant to be an open forum for opinions on process improvement. Product Owner Scrum Master The Team Subject Matter Expert Understand the domain well enough to envision a product. Answer questions on the domain for those creating the product. Business Advocate Understand the needs of the organization paying for the
software's construction and select a mix of features that
serve their goals. End User Advocate Describe the product with the understanding
of users and use and of a product that
serves both. Customer Advocate Understand the needs of the business
buying the product and select a mix of
features valuable to the customer. Communicator Capable of communicating vision and intent
effectively to allow detailed implementation
discussions to be made just in time. Decision Maker Given a variety of conflicting goals and
options, be the final decision maker for
hard product decisions. Process Champion Ensures the scrum process is followed as closely
and efficiently as possible. Block Remover Works to remove any impediments the team may have
in the way of completing their work. Runs most scrum-related meetings. Buffer Shields team from unnecessary interactions that
may be unhealthy for the process. Cross-functional Aware of each other's strengths and work together
to support one another to meet the sprint goal. Agreeable & Accountable Sprints are planned as a group so that each team member
may provide input - the result being unanimous estimations
to which the team is held accountable. Self-organizing No tasks are assigned to any one developer. The
team knows how best to meet the sprint goal. 100% Dedicated It is important that the team be focused on a single project
throughout the development cycle. The Product Owner is responsible for maximizing return on investment by identifying product features, translating these into a prioritized feature list, deciding which should be at the top of the list for the next Sprint, and continually reprioritizing and refining the list. 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 be successful. The Team builds the product that the customer is going to use. The team in Scrum is cross-functional and includes all the expertise necessary to deliver the potentially shippable product each Sprint. It is also self-organizing (self-managing), with a very high degree of autonomy and accountability. Product Owner The product backlog is the sole responsibility of the product owner. It leads the way ahead for the scrum team and needs to be continually updated and prioritized. Deploy Product Backlog Sprint Cycle Description Product Backlog work begins at the project's planning phases and continues as long as the team is developing the product. The Product Owner may make any additions or changes to the backlog before, during or after the sprint in accordance with the changing business needs. Occurrence Plan Scrum Develop Review 1 to 4 weeks - Product Backlog Artifacts Roles Involved Product Owner The planning meeting is when the team gets together to choose which backlog items will be included in the upcoming sprint. The Scrum Master directs the meeting. The product owner attends to answer any questions about the backlog items. The team collaborates to agree on estimations and ultimately decides the workload. Description The planning meeting occurs on or just before the next scheduled sprint. It might be every week if the team decides on 1 week sprints or it could be every month. The meeting should take no longer than 8 hours. Occurrence - Sprint Backlog
- New Sprint Artifacts Roles Involved Scrum Master The Team The team begins development work on the items within the sprint backlog. The order in which work is done is completely up to the team. Each day task statuses are updated along with time worked and time left to complete. The team remains focused completely on the sprint goal with little to no outside interference. Description The development begins after the sprint planning meeting and sprint backlog is complete. It continues until the end of the scheduled sprint length, 1 to 4 weeks. Occurrence - Updated tasks
- Completed work Artifacts Roles Involved The Team Collaborate The daily scrum is meant to be a consistent and short meeting to give the all members of the scrum team the opportunity to report on progress and obstacles. The three guiding questions are - what was accomplished since the last scrum, what will be accomplished today and are there any blocks we can assist with. Description Daily scrums are to be time-boxed at 15 minutes and should be scheduled each day at a consistent time. Occurrence Product Owner Roles Involved Scrum Master The Team Product Owner There are 2 parts to the review process. The first is a product demonstration to the stakeholders to show the work that was just completed during the sprint. This feedback is valuable from both a transparency perspective as well as an expectations perspective in that any stakeholder issues with delivered work may be worked on immediately during the next sprint. The second part is a retrospective with the scrum team only to discuss the pros and cons on the last sprint and how to better the process. Description The review process happens at the end of each sprint. You may choose to schedule the product demo and retrospective on the same morning you have scheduled the planning meeting for the next sprint. Occurrence - Completed sprint backlog
- Satisfied stakeholders
- Scrum process refinement Artifacts Roles Involved Scrum Master The Team Stakeholders Stakeholders Sprint Goals The output of each sprint should be code that is potentially shippable - but shipping is not a requirement! Sprint Code Production Trunk Governance Compliance Corporate Policy Pigs and chickens... Stakeholders Scrum Team Agile values... Questions?