Managing Agile Projects using Scrum Framework
2 likes335 views
The document outlines the Scrum framework as a method for managing agile projects, detailing its history, roles, stages, and processes. It describes key components such as the product backlog, sprints, daily stand-ups, and reviews, emphasizing the importance of team collaboration and continuous improvement. Additionally, it highlights the iterative nature of Scrum and the roles of the product owner, team, and scrum master in maximizing project success.
Managing Agile Projects using Scrum Framework
- 1. Managing Agile Projects using Scrum Framework
- 3. History The First Scrum Scrum was started in 1993 for software teams at Easel Corporation, where Jeff Sutherland was VP of object technology hired as chief engineer to lead a small team developing the first object-oriented design and analysis tool that incorporated round-trip engineering and automated object-relational mapping in enterprise development. (www.scruminc.com/wp- content/uploads/2014/07/The-Scrum- Handbook.pdf ) 3 Google AdWords Project The Art of Scrum && Quintuple- Constraint Project Objectives: I. Scrum project management experimentation for two project-ready GADW applications II. Debrief and evaluation of Scrum administration, or any adjustments thereof. III. Implementation, including any variations for the greater good of Google, company-wide, as the bonafide deliverable. (www.alexanderjsingleton.com/google- adwords-the-art-of-scrum-quintuple- constraint/ )
- 4. Table of contents 1. Scrum at a Glance. 2. Scrum Stages. 3. The Scrum Roles. 4. How Scrum Works? a. Using Backlog. b. Sprint Planning. c. Daily Standup. d. Updating Sprint Backlog & Burndown chart. e. Product backlog refinement & ending the spring. f. Sprint Review. g. The Sprint Retrospective. h. Updating Release Backlog & Burndown Chart. i. Starting the Next Sprint. j. Release Sprint. k. Release Planning & Initial Product Backlog Refinement. 4 The refrencess for each section will be added in the last page .
- 5. “ Scrum is an iterative, incremental framework for projects and product or application development, Scrum structures development in cycles of work called Sprints. These iterations are less than one month in length, and usually measured in weeks.. 5 Each Sprint, a cross-functional team selects items (customer requirements) from a prioritized list. They commit to complete the items by the end of the Sprint. During the Sprint, the chosen items do not change. Every day the Team gathers briefly to re-plan its work to optimize the likelihood of meeting commitments. At the end of the Sprint, the team reviews the Sprint with stakeholders, and demonstrates what they have built. People obtain feedback that can be incorporated in the next Sprint. Scrum at a Glance
- 7. Scrum stages (Cont.) 7 The Product Backlog The Product Backlog is a prioritized list of what’s required, ranked in order of value to the customer or business, with the highest value items at the top of the list. The Product Backlog evolves over the lifetime of the project, and items are continuously added, removed or reprioritized. The Sprint Scrum structures product development in cycles of work called Sprints, iterations of work that are typically 1–4 weeks in length. The Sprints are of fixed duration and end on a specific date whether the work has been completed or not; they are never extended. Sprint Review After the Sprint ends, there is the Sprint Review, where the Scrum Team and stakeholders inspect what was done during the Sprint, discuss it, and figure out what to do next. Present at this meeting are the Product Owner, Team Members, and Scrum Master, plus customers, stakeholders, experts, executives, and anyone else interested. Daily Standup Once the Sprint has started, the Team engages in another of the key Scrum practices: The Daily Stand-Up Meeting. This is a short (15 minutes) meeting that happens every workday at an appointed time. Sprint Retrospective Following the Sprint Review, the team gets together for the Sprint Retrospective which is an opportunity for the team to discuss what’s working and what’s not working, and agree on changes to try. Sprint Planning At the beginning of each Sprint, the Sprint Planning Meeting takes place. The Product Owner and Team (with facilitation from the Scrum Master) reviews the Product Backlog,
- 8. The Scrum Roles The Product Owner is responsible for maximizing return on investment (ROI) 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 re- prioritizing and refining the list. The Team builds the product that the customer is going to use: the application or website, for example. The Scrum team 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. 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. 8 In Scrum, there are three primary roles: - The Product Owner, - The Team and - The Scrum Master. Note : There is no role of project manager in Scrum. Sometimes an (ex-) project manager can step into the role of Scrum Master, there is a fundamental difference between the two roles, both in day-to-day responsibilities.
- 9. How Scrum Works? Initiating a Scrum project is not hard, as long as one takes one step at a time, and makes sure that everyone feels included. 9
- 10. THE FISRT STEP in Scrum is for the Product Owner to articulate the product vision. Eventually, this evolves into the refined and prioritized list of features. The Backlog is the product road map. Using Backlog Product Owner The Product Backlog is continuously updated by the Product Owner to reflect changes in the needs of the customer, new ideas or insights, moves by the competition, technical hurdles that appear, and so forth. 10 Project Team The team provides the Product Owner with estimates of the effort required for each item on the Product Backlog. In addition, the Product Owner is responsible for assigning a business value estimate to each individual item. This is often an unfamiliar practice for a Product Owner. Note : Only a single Product Backlog exists; this means the Product Owner is required to make prioritization decisions across the entire spectrum.
- 11. The Product Backlog leads the way ahead for the Scrum Team. Using Backlog (Cont.) 11
- 13. THE SECOND STEP is sprint planning. The Sprint Planning Meeting opens the Sprint. It is divided into two distinct sub-meetings, the first of which is called Sprint Planning Part One and the second part two. Sprint Planning Sprint Planning Part 1 The Product Owner and Team (with facilitation from the Scrum Master) review the high-priority items in the Product Backlog. The Product Owner and Team also review the “Definition of Done” that all items must meet, such as, “Done means coded to standards, reviewed, implemented with unit test-driven development (TDD), tested with 100 percent test automation, integrated, and documented. 13 Sprint Planning Part 2 referred to as Sprint Refinement, focuses on detailed task planning for how to implement the items that the team decides to take on. The Team selects the items from the Product Backlog they commit to complete by the end of the Sprint, starting at the top of the Product Backlog (in others words, starting with the items that are the highest priority for the Product Owner) and working down the list in order. This definition of “done” ensures transparency and quality fit for the purpose of the product and organization.
- 14. Daily Standup Sprint has started Once the Sprint has started, the Team engages in another of the key Scrum practices: The Daily Standup. This is a short (15 minutes or less) meeting that happens every workday at an appointed time and place. Everyone on the Team attends. To keep it brief, it is recommended that everyone remain standing. It is the Team’s opportunity to talk to each other and inspect each other’s progress and obstacles. In the Daily Standup, one by one, each member of the team reports three (and only three) things to the other members of the team: Daily Standup is not The Daily Standup is not a status meeting or a report to a manager; it is a time for a self- organizing Team to share with each other what is going on, to help it coordinate its work and optimize its likelihood of meeting its commitments. Someone makes note of the blocks, and the Scrum Master is responsible for helping team members resolve them. Daily Standup in a follow-up the Daily Standup in a follow-up meeting, although in Scrum no one is required to attend this. This follow-up meeting is a common event where the Team adapts to the information they heard in the Daily Standup: in other words, another inspect and adapt cycle. It is generally recommended not to have managers or others in positions of perceived authority attend the Daily Standup. This risks making the Team feel “monitored” under pressure to report major progress every day (an unrealistic expectation), and inhibited about reporting problems and it tends to undermine the Team’s self management, and invite micromanagement 14 • What did I do yesterday that helped the Development Team meet the Sprint Goal? • What will I do today to help the Team meet the Sprint Goal? • Do I see any impediment that prevents me or the Team from meeting the Sprint Goal?
- 15. Updating Sprint Backlog & Sprint Burndown Chart (Stories) Every day, the Team members update their estimate of the amount of time remaining to complete their current task in the Sprint Backlog. If the burndown line is not tracking downwards towards completion by mid-Sprint, the team needs to execute the Scrum Emergency Procedure: 1. Change the approach to the work or remove impediments to increase velocity. 2. Get help by having someone outside the team take some of the backlog. 3. Reduce the scope of work. 4. Abort the Sprint. 15
- 16. Product Backlog Refinement & Ending the Sprint A regularly scheduled Weekly meeting with the Product Owner is enough for experienced Teams to refine the Product Backlog. This refinement activity is not for items selected for the current Sprint; it is for items for the future, most likely in the next one or two Sprints. One of the lesser known, but valuable, guidelines in Scrum is that five or ten percent of each Sprint must be dedicated by the Product Owner and the team to refining the Product Backlog. This includes: • Detailed requirements analysis. • Splitting large items into smaller ones. • Estimation of new items. • Re-estimation of existing items. 16 Ending The Spring Teams typically over-commit in the first few Sprints and fail to meet objectives. Teams might then overcompensate and under-commit, and finish early. But by the third or fourth Sprint, a Team typically has figured out what it are capable of delivering (most of the time), and it will meet its Sprint goals more reliably after that. Teams are encouraged to pick one duration for Sprints (say, two weeks) and not change it.
- 17. Sprint Review After the Sprint ends, there is the Sprint Review, where the team reviews the Sprint with the Product Owner. The most important element of the Review is an in-depth conversation and collaboration between the Team and Product Owner to learn the situation, to get advice, and so forth. The review includes a demo of what the Team built during the Sprint, but if the focus of the review is a demo rather than conversation, there is an imbalance 17
- 18. The Sprint Retrospective It’s an opportunity for the entire Scrum Team to discuss what’s working and what’s not working, and agree on changes to try. The Sprint Review involves inspect and adapt regarding the product. The Sprint Retrospect tive, which follows the Review, involves inspect and adapt regarding the process. This is a practice that some teams skip which is unacceptable, because self organization requires the frequent regular reflection provided by the Retrospective. It’s the main mechanism for taking the visibility that Scrum provides into areas of potential improvement, and turning it into results. 18
- 19. Updating Release Backlog & Burndown Chart At this point, some items have been finished, some have been added, some have new estimates, and some have been dropped from the release goal. The Product Owner is responsible for ensuring that these changes are reflected in the Release Backlog (and more broadly, the Product Backlog). In addition, Scrum includes a Release Burndown chart that shows progress towards the release date 19
- 20. Starting the Next Sprint Following the Sprint Review, the Product Owner may update the Product Backlog with any new insights. At this point, the Product Owner and Team are ready to begin another Sprint cycle. There is no down time between Sprints – teams normally go from a Sprint Retrospective one afternoon into the next Sprint Planning the following morning (or after the weekend). One of the principles of agile development is “sustainable pace”, and only by working regular hours at a reasonable level can teams continue this cycle indefinitely. 20
- 21. Release Sprint The perfection vision of Scrum is that the product is potentially shippable at the end of each Sprint, which implies there is no wrap up work required, such as testing or documentation. Rather, the implication is that everything is completely finished every Sprint; that you could actually ship it or deploy it immediately after the Sprint Review. One of the principles of agile development is “sustainable pace”, and only by working regular hours at a reasonable level can teams continue this cycle indefinitely. A goal of any Scrum Team is to minimize the number of Release Sprints for completing “undone” work. Undone work tends to accumulate exponentially and causes poor product quality. 21
- 22. Release Planning & Initial Product Backlog Refinement A question that is sometimes asked is how, in an iterative model, can long-term release planning be done. There are two cases to consider: 1. A new product in its first release. 2. An existing product in a later release. In the case of a new product, or an existing product just adopting Scrum, there is the need to do initial Product Backlog refinement before the first Sprint, where the Product Owner and team shape a proper Scrum Product Backlog. This could take a few days or a week, and involves a vision workshop, some detailed requirements analysis, and estimation of all the items identified for the first release. 22
- 23. 58% Of companies around the world using Aglie Scrum Methodology 23
- 24. Thank you very much for your time 24 If you have any questions about this document please don’t hesitate to contact me at: ▪ https://www.linkedin.com/in/yasmeen-h-odeh ▪ Yasmeen odeh@live.com ▪ @Omnix International L.L.C