Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

Scrum process framework

•
•

Do you want to understand how Scrum is used practically? This presentation will be a perfect start for you.

1 of 28
Download to read offline
SCRUM Process Framework Prepared by : Iheb OMRI IT Analyst Certified Scrum master Certified Scrum Product Owner IHEB OMRI 1
SCRUM Manifesto SCRUM members and responsibilities SCRUM events SCRUM artifacts IHEB OMRI 2
Agile Manifesto IHEB OMRI 3
SCRUM Members and responsibilities IHEB OMRI 4
Events of the SCRUM Process •SCRUM teams will hold a retrospective meeting at the end of each sprint so that all team members can give input on what is working well and what is not working well. 1.What worked well during the last sprint? •2.What did not work very well during the last sprint? •3.What should we improve? Sprint retrospective •At the end of a sprint, the SCRUM Master will organize a sprint demo where the items of the sprint that have just ended can be shown to key stakeholders. Anyone in the company who is interested can turn up and watch the team demonstrate wh at they have built. Sprint demo •The daily stand-up is a daily meeting of no more than 15 minutes where each member of the team gives a brief update of how their work is progressing. Daily stand-up •The process of selecting which items to work on during the sprint is done during the sprint planning meeting. Sprint planning is time-boxed to a maximum of 8 hours. Sprint planning •A sprint is usuall y 1-week to 4- week duration. The team will attempt to begin, finish, and release work during this time The sprint IHEB OMRI 5
•A product backlog is a living document, which means it changes and gets updated as the team learns more, as market conditions change, as competitors bring out new products, and as customers give input into what they need. •For each item in the product backlog, you should add some additional information: •Description •Order (as in the priority order within the whole backlog list) •Estimate •Value to the business Product backlog •After the sprint planning, the team has committed to a developed plan to work on a chosen set of items in the next sprint. •Those items are then removed from the product backlog and moved into the sprint backlog. The sprint backlog is guided by the sprint goal (which is the stated outcome objective of the sprint) Sprint backlog •A burndown chart is a graphical representation of the amount of estimated remaining work. Typically the chart will feature the amount of remaining work (perhaps in hours) on the vertical axis with time along the horizontal axis. Burndown charts •The most important artifact is the actual product improvements, or in other words, the new code which has been written to enhance the features or usability of your product. Product increment IHEB OMRI 6
SCRUM Framework Process and best practices IHEB OMRI 7
SCRUM Framework IHEB OMRI 8
Step 1. Product Backlog Creation Step 2. Sprint Planning and Sprint Backlog Creation Step 3. Working on the Sprint. Scrum Meetings Step 4. Testing and Product Demonstration Step 5. Retrospective and Next Sprint Planning IHEB OMRI 9
Step 1. Product Backlog Creation The product backlog is the core deliverable that maintains and evolves the requirements in an agile environment. Ownership by the product owner. A product backlog contains a complete list of all requirements under consideration (written using a user story syntax – more on that below), rank ordered, and matrixed with other key characteristics that facilitate planning and prioritization. The most important items are shown at the top of the product backlog so the team knows what to deliver first. The development team doesn't work through the backlog at the product owner's pace and the product owner isn't pushing work to the development team. Instead, the development team pulls work from the product backlog as there is capacity for it. A team's roadmap and requirements provide the foundation for the product backlog. Roadmap initiatives break down into several epics, and each epic will have several requirements and user stories. The product owner then organizes each of the user stories into a single list for the development team. The product owner may choose to deliver a complete epic first. Or, it may be more important to the program to test booking a discounted flight which requires stories from several epics. IHEB OMRI 10
Product backlog prioritization The product backlog itself is owned by the product owner. The product owner’s job is to produce the very best product possible, so that means developing the most valuable additions to the software first. Since the product backlog is ranked in order of most valuable components, it would stand to reason that the most valuable addition would be at the very top. But that’s not necessarily the case, as the most valuable addition likely has dependencies that need to be developed first. Higher-priority items should be refined and have great value to the product. Mid-priority items should be candidates for refinement (the process of detailing each task) Low-priority items should not be a dependency and can be safely ignored until they are candidates for refinement. As items progress closer to the top of the list to be added to the next sprint cycle, they should be refined so they can be better acted upon. IHEB OMRI 11
Once the product backlog is built, it's important to regularly maintain it to keep pace with the program. Product owners should review the backlog before each iteration planning meeting to ensure prioritization is correct and feedback from the last iteration has been incorporated. Regular review of the backlog is often called "backlog grooming" in agile circles(some use the term backlog refinement). Once the backlog gets larger, product owners need to group the backlog into near-term and long-term items. Near-term items need to be fully fleshed out before they are labeled as such. This means complete user stories have been drawn up, collaboration with design and development has been sorted out, and estimates from development have been made. Longer term items can remain a bit vague, though it's a good idea to get a rough estimate from the development team to help prioritize them. The key word here is "rough": estimates will change once the team fully understands and begins work on those longer term items. The backlog serves as the connection between the product owner and the development team. The product owner is free to re-prioritize work in the backlog at any time due to customer feedback, refining estimates, and new requirements. Once work is in progress, though, keep changes to a minimum as they disrupt the development team and affect focus, flow, and morale. Keeping the backlog healthy IHEB OMRI 12
Product refinement is the process of refining the tasks in the product backlog so that they’re clear enough to be action items instead of nebulous ideas. PBR is a collaborative discussion process which starts at the end of one sprint to confirm whether the backlog is ready for the next sprint. The Objective of PBR meeting: A lot of time is saved at sprint planning meetings, if the backlogs are well maintained. If the backlog item is clearly specified in the acceptance criteria and cross-checked properly by the team members, the planning process can be accomplished prior to the meeting. PBR offers the team members the opportunity to interact with each other regarding stories. Why is PBR important? PBR and its sessions are important mainly due to the following features- •It increases the efficiency of the team by reducing uncertainty •Properly refined stories are easy to estimate, test and implement. •PBR session increases the efficiency of the team due to the knowledge shared among the team members. •If PBR meeting is maintained properly, it helps reduce the time for a Sprint planning meeting. Product Backlog Refinement (PBR) IHEB OMRI 13
Step 2. Sprint Planning and Sprint Backlog Creation A sprint planning meeting is conducted before the start of a sprint. The purpose of this meeting is to determine the sprint plan and set a sprint goal. Sprint planning includes agreeing on the number of backlog items in the sprint that is the responsibility of the development team and as well as to define the goal for the current sprint and sprint backlog. During the sprint planning meeting, the product owner describes the highest priority features to the entire team. They will then discuss which stories the team will do in that sprint. The meeting should be attended by the whole team. If additional expertise on specific backlog items are required, then stakeholders can be also invited. The team may include the refinement sessions as well. IHEB OMRI 14
Sprint Planning Meeting – Part I Part one of the sprint planning meeting is a review of the product backlog items the Product Owner will ask the team to forecast and deliver. This is the time for the product owner to describe what he wants to make available by the end of the next sprint. During this part of the meeting, it is not uncommon for the team to banter back and forth with the product owner, asking clarifying questions and driving away ambiguity. By the end of sprint planning part one, the team will select a sprint goal: a one-sentence description of the overall outcome of the sprint. This helps later when questions about depth and breadth come up: if the work does not directly tie to the sprint goal, then it is not done during the sprint. The key activities to be conducted in Part I of the Sprint Planning Meeting are: •During the first session the Product Owner presents the highest priorities of the Product Backlog to the team. •Set the sprint goal or objective – Product Owner together with the development team think of the objective of the sprint. •The team and the Product Owner collaborate to help the team determine what functionality can be delivered in the upcoming Sprint. •The team commits to this Product Backlog at the end of the session – Selected Product Backlog. IHEB OMRI 15
Sprint Planning Meeting – Part II The team decides how the work will be built. In this meeting the team will begin decomposing the product backlog items into work tasks and estimating these in hours. The product owner must be available during this meeting but does not have to be in the room. In fact, many teams find it helpful to work without product owner during this detailed part of the meeting. Knowing that the product owner is available yet not having her observing all of the discussion about the best way to implement a feature can be freeing for many teams. The key activities of the Part II of Sprint Planning are: •During the second session of the meeting, the team plans how it will meet this commitment by detailing its work as a plan in the Sprint Backlog. • Detail planning – Breakdown stories into tasks, ensure the team has separated the stories into tasks, as this will enable the team to consider everything that should be done to finish the stories. It’s additionally great practice to make Testing as a different task. • Estimating of the stories – Teams can do the measuring of the stories utilizing strategies like Planning Poker or T- Shirt Sizing and Allow team members to sign up for the work they choose and give an estimate as for how long each task will take to complete. IHEB OMRI 16
Step 3. Working on the Sprint. Scrum Meetings All team members are required to attend scrum meetings. Since both the Scrum Master and product owner are committed team members, they are expected to attend and participate. Anyone else (for example, a departmental VP, a salesperson or a developer from another project) is allowed to attend, but is there only to listen. This makes scrum meetings an excellent way for a Scrum team to disseminate information . The daily scrum meeting is not used as a problem-solving or issue resolution meeting. Issues that are raised are taken offline and usually dealt with by the relevant subgroup immediately after the meeting. During the daily scrum, each team member answers the following three questions: 1.What did you do yesterday? 2.What will you do today? 3.Are there any impediments in your way? By focusing on what each person accomplished yesterday and will accomplish today, the team gains an excellent understanding of what work has been done and what work remains. The daily scrum meeting is not a status update meeting in which a boss is collecting information about who is behind schedule. Rather, it is a meeting in which team members make commitments to each other. IHEB OMRI 17
Step 4. Testing and Product Demonstration Members that attend the meeting are: The Scrum Team and stakeholders (users, other teams, managers, investors, sponsors, customers, etc.) •The Product Owner opens the meeting and tells the attendees what the Development Team completed during the current Sprint (what has been "Done" and “not Done”). •The Development Team demonstrates the "Done" functionality (Demo), answers the questions and discusses problems they met on their way. •The Product Owner discusses the current state of the Product Backlog, marketplace changes, and forecasts the likely release dates. •The attendees collaborate on the Product Backlog Items, which can be completed during the next Sprint. Thus, the stakeholders get a shared understanding of the future work. •A review of the budget, timeline, potential capabilities follows. IHEB OMRI 18
The Sprint Review is not just about product demonstration, it is an inspection of the completed Sprint, the Product Backlog and the marketplace. Also, it is a place for reviewing budgets, timeline and capabilities. Each Sprint is an important risk mitigation tool and the Sprint Review is a decision point for the Product Owner. Each Sprint can be the last one. The Product Owner makes a formal decision regarding financing the next Sprint during the Sprint Review. Here are some decisions that can be formally made: •Stopping/Pausing the development •Financing the next Sprint •Adding team(s) with an assumption that it will speed up the development •Releasing Increment (can be done anytime during the Sprint) IHEB OMRI 19
Step 5. Retrospective and Next Sprint Planning As described in the Scrum Guide, the Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. This is at most a three- hour meeting for one-month Sprints. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose. This is the opportunity for the Scrum Team to improve and all member should be in attendance. During the Sprint Retrospective, the team discusses: •What went well in the Sprint •What could be improved •What will we commit to improve in the next Sprint IHEB OMRI 20
The Scrum Master encourages the Scrum Team to improve its development process and practices to make it more effective and enjoyable for the next Sprint. During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of “Done” if appropriate and not in conflict with product or organizational standards. By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint. Implementing these improvements in the next Sprint is the adaptation to the inspection of the Scrum Team itself. Although improvements may be implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on inspection and adaptation. IHEB OMRI 21
http://www.deltalounge.n et/wpress/wp- content/uploads/2012/03 /ScrumGuideMindMap.pn g IHEB OMRI 22
Scrum workflow states (TFS) IHEB OMRI 23
•The product owner creates a PBI or a tester creates a bug in the New state with the default reason, New backlog item •The product owner moves the item to Approved after it is sufficiently described and ready for the team to estimate the level of effort. Most of the time, items near the top of the Product Backlog are in the Approved state, while items toward the middle and bottom are in a New state •The team updates the status to Committed when they decide to commit to working on it during the sprint •The item is moved to the Done state when the team has completed all its associated tasks and the product owner agrees that it has been implemented according to the Acceptance Criteria. PBIs and bugs follow this typical workflow progression: IHEB OMRI 24
6 Best Practices to Start a Scrum Project1. Create the Product Vision & Product Backlog Together Often the customer has an idea about the product and its possibilities but a Product Backlog is still missing. A good practice is to organise a workshop with the customer and the supplier’s Development Team and letting them create the Product Backlog together. Even before setting up the contract. Ideally you also create the product vision to ensure mutual understanding. By creating the product vision and Product Backlog together the customer and supplier really get to know each other. More important: the customer meets the actual Development Team. They are the ones who are going to realise his dream. They are the ones he needs to trust. 2. Estimate the Implementation Effort of the Product Backlog Together After creating the Product Backlog together it’s also possible to estimate it in the presence of the customer. The advantage is the customer hears all the discussions & questions and can answer them directly. Possible complexity is also detected and discussed together which ensures mutual understanding about the given estimations. IHEB OMRI 25
3. Determine the Business Value of the Product Backlog Together When the Product Backlog is estimated in implementation effort, the next step is determining the business value. This is up to the stakeholders. In the same session, facilitate the stakeholders to discuss and determine the business value for every Product Backlog Item using business value points. The goal is a shared understanding of the priorities and inviting the stakeholders to participate in defining what is more valuable. This exercise forces them to prioritize the Product Backlog without delegating this responsibility entirely to the Product Owner. After estimating the implementation effort (done by the Development Team) and determining the business value (done by the stakeholders) the following matrix will appear. This offers great insights like: •PBI D, E, F and G have a low implementation effort and lot’s of business value. So start with these items first. •PBI H and I will take quite some effort to implement and won’t offer much business value. So do we really want this on the Product Backlog? 4. Clarify Dependencies Between Product Backlog Items When the implementation effort and business value is determined for every Product Backlog Item, it’s time to detect the dependencies. Technical dependencies can be clarified by the Development Team, functional dependencies might also be detected by the Product Owner and stakeholders. This offers insights like: •PBI C is a bottleneck. Discuss this item in more detail to solve the dependencies. •PBI J and K also have a dependency, so take this into account when ordering the Product Backlog IHEB OMRI 26
5. Invite the Customer to the Scrum Events Invite the customer to all the Scrum events. Let the customer experience how the Daily Scrum is done, let them experience the discussions during the Sprint Planning and share all the lessons learned during the Sprint Review. Most important of course is to gather feedback about the delivered product and evaluate the collaboration. 6. Decide Sprint Length The Sprint length (which should be kept constant) should be decided. It should not be too long, in order to avoid “water fallising” the sprints and reduce the rhythm of delivery. Not too short, in order to allow meaningful value built in the increment. In any cases, it should be kept within the limits set by the framework (i.e. 4 weeks at maximum). Consider also organizational limitations or guidelines (e.g. Predefined release dates, shared testing infrastructure availability, etc). IHEB OMRI 27
Do user stories replace a requirements document? Agile projects, especially Scrum ones, use a product backlog, which is a prioritized list of the functionality to be developed in a product or service. Although product backlog items can be whatever the team desires, user stories have emerged as the best and most popular form of product backlog items. While a product backlog can be thought of as a replacement for the requirements document of a traditional project, it is important to remember that the written part of an agile user story (“As a user, I want …”) is incomplete until the discussions about that story occur. It’s often best to think of the written part as a pointer to the real requirement. User stories could point to a diagram depicting a workflow, a spreadsheet showing how to perform a calculation, or any other artifact the product owner or team desires.https://www.mountaingoatsoftware.com/agile/user-stories IHEB OMRI 28

More Related Content

Scrum process framework

  • 1. SCRUM Process Framework Prepared by : Iheb OMRI IT Analyst Certified Scrum master Certified Scrum Product Owner IHEB OMRI 1
  • 2. SCRUM Manifesto SCRUM members and responsibilities SCRUM events SCRUM artifacts IHEB OMRI 2
  • 4. SCRUM Members and responsibilities IHEB OMRI 4
  • 5. Events of the SCRUM Process •SCRUM teams will hold a retrospective meeting at the end of each sprint so that all team members can give input on what is working well and what is not working well. 1.What worked well during the last sprint? •2.What did not work very well during the last sprint? •3.What should we improve? Sprint retrospective •At the end of a sprint, the SCRUM Master will organize a sprint demo where the items of the sprint that have just ended can be shown to key stakeholders. Anyone in the company who is interested can turn up and watch the team demonstrate wh at they have built. Sprint demo •The daily stand-up is a daily meeting of no more than 15 minutes where each member of the team gives a brief update of how their work is progressing. Daily stand-up •The process of selecting which items to work on during the sprint is done during the sprint planning meeting. Sprint planning is time-boxed to a maximum of 8 hours. Sprint planning •A sprint is usuall y 1-week to 4- week duration. The team will attempt to begin, finish, and release work during this time The sprint IHEB OMRI 5
  • 6. •A product backlog is a living document, which means it changes and gets updated as the team learns more, as market conditions change, as competitors bring out new products, and as customers give input into what they need. •For each item in the product backlog, you should add some additional information: •Description •Order (as in the priority order within the whole backlog list) •Estimate •Value to the business Product backlog •After the sprint planning, the team has committed to a developed plan to work on a chosen set of items in the next sprint. •Those items are then removed from the product backlog and moved into the sprint backlog. The sprint backlog is guided by the sprint goal (which is the stated outcome objective of the sprint) Sprint backlog •A burndown chart is a graphical representation of the amount of estimated remaining work. Typically the chart will feature the amount of remaining work (perhaps in hours) on the vertical axis with time along the horizontal axis. Burndown charts •The most important artifact is the actual product improvements, or in other words, the new code which has been written to enhance the features or usability of your product. Product increment IHEB OMRI 6
  • 7. SCRUM Framework Process and best practices IHEB OMRI 7
  • 9. Step 1. Product Backlog Creation Step 2. Sprint Planning and Sprint Backlog Creation Step 3. Working on the Sprint. Scrum Meetings Step 4. Testing and Product Demonstration Step 5. Retrospective and Next Sprint Planning IHEB OMRI 9
  • 10. Step 1. Product Backlog Creation The product backlog is the core deliverable that maintains and evolves the requirements in an agile environment. Ownership by the product owner. A product backlog contains a complete list of all requirements under consideration (written using a user story syntax – more on that below), rank ordered, and matrixed with other key characteristics that facilitate planning and prioritization. The most important items are shown at the top of the product backlog so the team knows what to deliver first. The development team doesn't work through the backlog at the product owner's pace and the product owner isn't pushing work to the development team. Instead, the development team pulls work from the product backlog as there is capacity for it. A team's roadmap and requirements provide the foundation for the product backlog. Roadmap initiatives break down into several epics, and each epic will have several requirements and user stories. The product owner then organizes each of the user stories into a single list for the development team. The product owner may choose to deliver a complete epic first. Or, it may be more important to the program to test booking a discounted flight which requires stories from several epics. IHEB OMRI 10
  • 11. Product backlog prioritization The product backlog itself is owned by the product owner. The product owner’s job is to produce the very best product possible, so that means developing the most valuable additions to the software first. Since the product backlog is ranked in order of most valuable components, it would stand to reason that the most valuable addition would be at the very top. But that’s not necessarily the case, as the most valuable addition likely has dependencies that need to be developed first. Higher-priority items should be refined and have great value to the product. Mid-priority items should be candidates for refinement (the process of detailing each task) Low-priority items should not be a dependency and can be safely ignored until they are candidates for refinement. As items progress closer to the top of the list to be added to the next sprint cycle, they should be refined so they can be better acted upon. IHEB OMRI 11
  • 12. Once the product backlog is built, it's important to regularly maintain it to keep pace with the program. Product owners should review the backlog before each iteration planning meeting to ensure prioritization is correct and feedback from the last iteration has been incorporated. Regular review of the backlog is often called "backlog grooming" in agile circles(some use the term backlog refinement). Once the backlog gets larger, product owners need to group the backlog into near-term and long-term items. Near-term items need to be fully fleshed out before they are labeled as such. This means complete user stories have been drawn up, collaboration with design and development has been sorted out, and estimates from development have been made. Longer term items can remain a bit vague, though it's a good idea to get a rough estimate from the development team to help prioritize them. The key word here is "rough": estimates will change once the team fully understands and begins work on those longer term items. The backlog serves as the connection between the product owner and the development team. The product owner is free to re-prioritize work in the backlog at any time due to customer feedback, refining estimates, and new requirements. Once work is in progress, though, keep changes to a minimum as they disrupt the development team and affect focus, flow, and morale. Keeping the backlog healthy IHEB OMRI 12
  • 13. Product refinement is the process of refining the tasks in the product backlog so that they’re clear enough to be action items instead of nebulous ideas. PBR is a collaborative discussion process which starts at the end of one sprint to confirm whether the backlog is ready for the next sprint. The Objective of PBR meeting: A lot of time is saved at sprint planning meetings, if the backlogs are well maintained. If the backlog item is clearly specified in the acceptance criteria and cross-checked properly by the team members, the planning process can be accomplished prior to the meeting. PBR offers the team members the opportunity to interact with each other regarding stories. Why is PBR important? PBR and its sessions are important mainly due to the following features- •It increases the efficiency of the team by reducing uncertainty •Properly refined stories are easy to estimate, test and implement. •PBR session increases the efficiency of the team due to the knowledge shared among the team members. •If PBR meeting is maintained properly, it helps reduce the time for a Sprint planning meeting. Product Backlog Refinement (PBR) IHEB OMRI 13
  • 14. Step 2. Sprint Planning and Sprint Backlog Creation A sprint planning meeting is conducted before the start of a sprint. The purpose of this meeting is to determine the sprint plan and set a sprint goal. Sprint planning includes agreeing on the number of backlog items in the sprint that is the responsibility of the development team and as well as to define the goal for the current sprint and sprint backlog. During the sprint planning meeting, the product owner describes the highest priority features to the entire team. They will then discuss which stories the team will do in that sprint. The meeting should be attended by the whole team. If additional expertise on specific backlog items are required, then stakeholders can be also invited. The team may include the refinement sessions as well. IHEB OMRI 14
  • 15. Sprint Planning Meeting – Part I Part one of the sprint planning meeting is a review of the product backlog items the Product Owner will ask the team to forecast and deliver. This is the time for the product owner to describe what he wants to make available by the end of the next sprint. During this part of the meeting, it is not uncommon for the team to banter back and forth with the product owner, asking clarifying questions and driving away ambiguity. By the end of sprint planning part one, the team will select a sprint goal: a one-sentence description of the overall outcome of the sprint. This helps later when questions about depth and breadth come up: if the work does not directly tie to the sprint goal, then it is not done during the sprint. The key activities to be conducted in Part I of the Sprint Planning Meeting are: •During the first session the Product Owner presents the highest priorities of the Product Backlog to the team. •Set the sprint goal or objective – Product Owner together with the development team think of the objective of the sprint. •The team and the Product Owner collaborate to help the team determine what functionality can be delivered in the upcoming Sprint. •The team commits to this Product Backlog at the end of the session – Selected Product Backlog. IHEB OMRI 15
  • 16. Sprint Planning Meeting – Part II The team decides how the work will be built. In this meeting the team will begin decomposing the product backlog items into work tasks and estimating these in hours. The product owner must be available during this meeting but does not have to be in the room. In fact, many teams find it helpful to work without product owner during this detailed part of the meeting. Knowing that the product owner is available yet not having her observing all of the discussion about the best way to implement a feature can be freeing for many teams. The key activities of the Part II of Sprint Planning are: •During the second session of the meeting, the team plans how it will meet this commitment by detailing its work as a plan in the Sprint Backlog. • Detail planning – Breakdown stories into tasks, ensure the team has separated the stories into tasks, as this will enable the team to consider everything that should be done to finish the stories. It’s additionally great practice to make Testing as a different task. • Estimating of the stories – Teams can do the measuring of the stories utilizing strategies like Planning Poker or T- Shirt Sizing and Allow team members to sign up for the work they choose and give an estimate as for how long each task will take to complete. IHEB OMRI 16
  • 17. Step 3. Working on the Sprint. Scrum Meetings All team members are required to attend scrum meetings. Since both the Scrum Master and product owner are committed team members, they are expected to attend and participate. Anyone else (for example, a departmental VP, a salesperson or a developer from another project) is allowed to attend, but is there only to listen. This makes scrum meetings an excellent way for a Scrum team to disseminate information . The daily scrum meeting is not used as a problem-solving or issue resolution meeting. Issues that are raised are taken offline and usually dealt with by the relevant subgroup immediately after the meeting. During the daily scrum, each team member answers the following three questions: 1.What did you do yesterday? 2.What will you do today? 3.Are there any impediments in your way? By focusing on what each person accomplished yesterday and will accomplish today, the team gains an excellent understanding of what work has been done and what work remains. The daily scrum meeting is not a status update meeting in which a boss is collecting information about who is behind schedule. Rather, it is a meeting in which team members make commitments to each other. IHEB OMRI 17
  • 18. Step 4. Testing and Product Demonstration Members that attend the meeting are: The Scrum Team and stakeholders (users, other teams, managers, investors, sponsors, customers, etc.) •The Product Owner opens the meeting and tells the attendees what the Development Team completed during the current Sprint (what has been "Done" and “not Done”). •The Development Team demonstrates the "Done" functionality (Demo), answers the questions and discusses problems they met on their way. •The Product Owner discusses the current state of the Product Backlog, marketplace changes, and forecasts the likely release dates. •The attendees collaborate on the Product Backlog Items, which can be completed during the next Sprint. Thus, the stakeholders get a shared understanding of the future work. •A review of the budget, timeline, potential capabilities follows. IHEB OMRI 18
  • 19. The Sprint Review is not just about product demonstration, it is an inspection of the completed Sprint, the Product Backlog and the marketplace. Also, it is a place for reviewing budgets, timeline and capabilities. Each Sprint is an important risk mitigation tool and the Sprint Review is a decision point for the Product Owner. Each Sprint can be the last one. The Product Owner makes a formal decision regarding financing the next Sprint during the Sprint Review. Here are some decisions that can be formally made: •Stopping/Pausing the development •Financing the next Sprint •Adding team(s) with an assumption that it will speed up the development •Releasing Increment (can be done anytime during the Sprint) IHEB OMRI 19
  • 20. Step 5. Retrospective and Next Sprint Planning As described in the Scrum Guide, the Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. This is at most a three- hour meeting for one-month Sprints. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose. This is the opportunity for the Scrum Team to improve and all member should be in attendance. During the Sprint Retrospective, the team discusses: •What went well in the Sprint •What could be improved •What will we commit to improve in the next Sprint IHEB OMRI 20
  • 21. The Scrum Master encourages the Scrum Team to improve its development process and practices to make it more effective and enjoyable for the next Sprint. During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of “Done” if appropriate and not in conflict with product or organizational standards. By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint. Implementing these improvements in the next Sprint is the adaptation to the inspection of the Scrum Team itself. Although improvements may be implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on inspection and adaptation. IHEB OMRI 21
  • 23. Scrum workflow states (TFS) IHEB OMRI 23
  • 24. •The product owner creates a PBI or a tester creates a bug in the New state with the default reason, New backlog item •The product owner moves the item to Approved after it is sufficiently described and ready for the team to estimate the level of effort. Most of the time, items near the top of the Product Backlog are in the Approved state, while items toward the middle and bottom are in a New state •The team updates the status to Committed when they decide to commit to working on it during the sprint •The item is moved to the Done state when the team has completed all its associated tasks and the product owner agrees that it has been implemented according to the Acceptance Criteria. PBIs and bugs follow this typical workflow progression: IHEB OMRI 24
  • 25. 6 Best Practices to Start a Scrum Project1. Create the Product Vision & Product Backlog Together Often the customer has an idea about the product and its possibilities but a Product Backlog is still missing. A good practice is to organise a workshop with the customer and the supplier’s Development Team and letting them create the Product Backlog together. Even before setting up the contract. Ideally you also create the product vision to ensure mutual understanding. By creating the product vision and Product Backlog together the customer and supplier really get to know each other. More important: the customer meets the actual Development Team. They are the ones who are going to realise his dream. They are the ones he needs to trust. 2. Estimate the Implementation Effort of the Product Backlog Together After creating the Product Backlog together it’s also possible to estimate it in the presence of the customer. The advantage is the customer hears all the discussions & questions and can answer them directly. Possible complexity is also detected and discussed together which ensures mutual understanding about the given estimations. IHEB OMRI 25
  • 26. 3. Determine the Business Value of the Product Backlog Together When the Product Backlog is estimated in implementation effort, the next step is determining the business value. This is up to the stakeholders. In the same session, facilitate the stakeholders to discuss and determine the business value for every Product Backlog Item using business value points. The goal is a shared understanding of the priorities and inviting the stakeholders to participate in defining what is more valuable. This exercise forces them to prioritize the Product Backlog without delegating this responsibility entirely to the Product Owner. After estimating the implementation effort (done by the Development Team) and determining the business value (done by the stakeholders) the following matrix will appear. This offers great insights like: •PBI D, E, F and G have a low implementation effort and lot’s of business value. So start with these items first. •PBI H and I will take quite some effort to implement and won’t offer much business value. So do we really want this on the Product Backlog? 4. Clarify Dependencies Between Product Backlog Items When the implementation effort and business value is determined for every Product Backlog Item, it’s time to detect the dependencies. Technical dependencies can be clarified by the Development Team, functional dependencies might also be detected by the Product Owner and stakeholders. This offers insights like: •PBI C is a bottleneck. Discuss this item in more detail to solve the dependencies. •PBI J and K also have a dependency, so take this into account when ordering the Product Backlog IHEB OMRI 26
  • 27. 5. Invite the Customer to the Scrum Events Invite the customer to all the Scrum events. Let the customer experience how the Daily Scrum is done, let them experience the discussions during the Sprint Planning and share all the lessons learned during the Sprint Review. Most important of course is to gather feedback about the delivered product and evaluate the collaboration. 6. Decide Sprint Length The Sprint length (which should be kept constant) should be decided. It should not be too long, in order to avoid “water fallising” the sprints and reduce the rhythm of delivery. Not too short, in order to allow meaningful value built in the increment. In any cases, it should be kept within the limits set by the framework (i.e. 4 weeks at maximum). Consider also organizational limitations or guidelines (e.g. Predefined release dates, shared testing infrastructure availability, etc). IHEB OMRI 27
  • 28. Do user stories replace a requirements document? Agile projects, especially Scrum ones, use a product backlog, which is a prioritized list of the functionality to be developed in a product or service. Although product backlog items can be whatever the team desires, user stories have emerged as the best and most popular form of product backlog items. While a product backlog can be thought of as a replacement for the requirements document of a traditional project, it is important to remember that the written part of an agile user story (“As a user, I want …”) is incomplete until the discussions about that story occur. It’s often best to think of the written part as a pointer to the real requirement. User stories could point to a diagram depicting a workflow, a spreadsheet showing how to perform a calculation, or any other artifact the product owner or team desires.https://www.mountaingoatsoftware.com/agile/user-stories IHEB OMRI 28