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
Agile - Scrum
Transcript of Agile - Scrum
Scrum What is agile Software development methods based on iterative and incremental development where requirements and solutions evolve through collaboration between self-organized, cross –functional teams.
It's the ability to inspect and adapt, reflect and refine, and efficiently and effectively manage the changes that inevitably occur.
Software Developers belief that a history of over budget projects was caused by volatile requirements and ambitions to create sweeping, improperly targeted product designs before any real code was written.
The technological evolution of communications and how individuals interact with one another.
The speed at which software development has increased, bringing systems closer to the business Manifesto 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. Empirical It is typical to adopt the defined (theoretical) modeling approach when the underlying mechanisms by which a process operates are reasonably well understood. When the process is too complicated for the defined approach, the empirical approach is the appropriate choice.
—B. A. Ogunnaike and W. H. Ray, Transparency Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. A chance to question the need for the document and producing anything that doesn't make sense, isn't valuable, or insn't useful - regardless of previous practice. Planning that does not preclude building your product. It is lightweight, efficient, and iterative. An open door for scope screep Flexible and transparent means of allowing stakeholders to request changes taking deliberate tradeoffs into consideration A 'rigid best practice' solution A set of guiding principles with a number of options: Scrum, XP, Kanban, Crystal Roles Rather Principles Product Owner Scrummaster
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
Process Champion: Ensures the scrum process is followed as closely and efficiently as possible. Runs most scrum-related meetings.
Block Remover: Works to remove any impediment may have in the way of completing their work
Buffer: Shields the team from unnecessary interactions that may be unhealthy for the team.
Enables cooperation Builds the product that the customer will use. The team is cross functionality and includes all the expertise necessary to deliver the potentially shippable product each sprint. It is self organizing, with a high degree of autonomy and accountability.
Cross functional: Aware of each others strengths and work together to support one another the meet the sprint goal
Agreeable and accountability: Sprints are planned as a group so that each team member may provide input- the result being estimations to which the team is held accountable
self Organizing: No tasks are assigned to anyone developer.
100% dedicated: Completely focused on one project
Comprised of 7/+- 2 people Product Owner Scrummaster Team Responsible for maximizing return on investment
Subject Matter Expert: Understands the domain well enough to envision a product.
Business Advocate: Understands the needs of the organization paying for the software’s construction
Customer Advocate: Understands the needs of the client buying the product ,selecting a set of features available to the customer
Communicator: Capable of communicating vision and intent effectively.
Decision Maker: Given a variety of conflicting goals and options, be the final decision maker for hard product decisions. Team An excuse to stop producting product documentation An opportunity to eliminate planning Agile is Not Process Product Vision Statement
Created by the Product Owner. An effective product vision guides the Scrum team and aligns stakeholders and customers.
Who is the target customer?
Which customer needs will the product address?
Which product attributes are critical to satisfy the needs selected?
How does the product compare against existing products?
What is the target timeframe and budget to develop and launch the product? Product Backlog Vision Statement Sprint Planning Sprint Review Daily Scrum Sprint Retrospective 24 hours The Backlog is the product roadmap existing throughout the life of the product
Contains all potential product "items" (new functionality, performance improvements, research, etc)
Used for release planning
Items do not have to be in the form of user stories, it could be use cases or any other requirement approach desired Sprint Planning Part 1:
What does the Product Owner want and why does he need it? Sprint Planning Part 2:
How to implement what the team decides to take on? The Product Owner discusses the sprint objectives and the next highest items that he would like to see implemented during the upcoming sprint.
What and Why
Last minute clarifications
The product owner may devise a 'Sprint Goal' which is a summary of the objectives
Provides the team with some scope flexibility, since even though not all items may be accomplished within the sprint, they should be able to produce tangible results towards that Sprint Goal Sprint Planning 1 Team forecasts the amount of items they can complete in the sprint starting at the top of the backlog and working down the list.
Determines all tasks and the hours to complete each task
Matches hours to complete tasks against available hours
Team estimates how much it will take rather than having it assigned to them, making it more reliable since it’s based on their own analysis and planning
The product owner has no control over how much the team determines it can take on
The team has the right to lobby for items they believe should be moved up the priority list (eg. Dependencies, the patients open) Sprint Planning 2 Every 2 - 4 Weeks The daily scrum is not a status meeting to report to a manager; it is a time for the self-organizing team to share with each other what is going on and to help them coordinate with one another
15 Minutes or Less
Each Individual answers 3 questions:
What have I worked on since the last meeting?
What will I working on until the next meeting?
What obstacles are in the way
There is little or no in depth conversation at the meeting. Any details should be discussed after the meeting or at another time.
Reporting of sprint progress is maintained via the task board and the sprint burn down chart Daily Scrum Product Inspection and Adaptation: Learn what is going on and evolve based on feedback
Conversation between the team, the product owner, and the stakeholders
Team: Discuss what is going on with the product and the team.
Product Ownder: Discuss the market.
The review includes using the actual live software that the team has built.
Should not take more than hour – 1 hour Sprint Review Team Inspection and Adaptation: Discuss how the team is working together and how it can be improved Sprint Retrospective Model of process control exercises frequent inspection and adaptation for processes that are imperfectly defined and generate unpredictable and unrepeatable outputs. What’s working?
What’s not working?
Agree to changes
Should always include positives and strength’s and not just negative feedback