Lecture 3 Agile Scrum PDF

Agile Software Engineering © Ian Sommerville 2018  Scrum Managers need information that will help them assess The cost to develop a software product How long it will take When the product can be rel...

Agile Software Engineering © Ian Sommerville 2018  Scrum Managers need information that will help them assess The cost to develop a software product How long it will take When the product can be released to market Plan-driven development provides this information through → long-term planning that identifies deliverables and associated dates Requirements/Plans always change so in practice only short-term plans are reliable Solution using XP: Plan incrementally (beginning of increment and/or during daily meetings) so that the overall plan can change in response to changing circumstances → good Planning should be informal with minimal documentation and with no designated project manager → problematic May be too informal, need a compromise solution Agile Software Engineering © Ian Sommerville 2018: 2  Scrum This informal approach to management led to the development of Scrum XP is focused on a set of technical practices (10 of them) Scrum provides a framework for agile project organization with additional designated individuals who act as the interface between the development team and the organization: the ScrumMaster and the Product Owner Scrum and XP can then compensate each other XP → practices Scrum → Project Management (Scrum was first used in a 1986 paper titled "The New Product Development Game". The term is borrowed from rugby, where a scrum is a formation of players. The term scrum was chosen by the paper's authors because it emphasizes teamwork-- Wiki) Agile Software Engineering © Ian Sommerville 2018: 3  Table 2.5 Scrum terminology Product The software product that is being developed by the Scrum team. Product owner A team member who takes the lead on refining product features. They review work done and help to test the product. (Also, responsible for ensuring that the development team always focuses on the product rather than diverted to technically interesting but less relevant work.) Decides whether to release a “Potentially shippable product increment” Product backlog A to-do list of items such as bugs, features and product improvements that the Scrum team have not yet completed. Development team A small self-organizing team of five to eight people who are responsible for developing the product. (A self-organizing team choose how best to accomplish their work, make decisions by consensus… rather than being directed by others outside of the team) Sprint A short period, typically two to four weeks, when a product increment is developed. Agile Software Engineering © Ian Sommerville 2018: 4  Table 2.5 Scrum terminology Scrum A daily team meeting where progress is reviewed and work to be done that day is discussed and agreed. ScrumMaster A team coach who guides the team in the effective use of Scrum. (The ScrumMaster facilitates how to properly use Scrum). In many companies, the ScrumMaster takes the role of the project manager. Potentially shippable product increment The output of a sprint which should be of high enough quality to be deployed for customer use (not necessarily the completed product). Minimum Viable Product (non-Scrum) A “Potentially shippable product increment” that is marketable, i.e., It has enough features that make it of value to most customers → more mature → somewhat ready to be deployed to the masses Velocity An estimate of how much work a team can do in a single sprint (unit used?). Agile Software Engineering © Ian Sommerville 2018: 5 Agile Software Engineering © Ian Sommerville 2018:  Scrum Process (revisited) In Scrum, software is developed in sprints, which are fixed-length periods (2 - 4 weeks) in which software features are developed and delivered. During a sprint, the team has daily meetings (Scrums) to review progress and to update the list of work items that are incomplete. Sprints should produce a ‘shippable product increment’. This means that the developed software increment should be complete and ready to be deployed. The “sprint backlog” is used to keep track of work that is to be done during that sprint. Sprint planning is based on the product backlog, which is a list of all the activities (not only features) that have to be completed to finish the product being developed. The highest-priority items on the product backlog are selected for implementation in the next sprint, they are placed in the sprint backlog. At the end of a sprint, incomplete items are returned to the product backlog. Sprints are never extended to finish an incomplete item. Agile Software Engineering © Ian Sommerville 2018: 7 Agile Software Engineering © Ian Sommerville 2018:  Scrum Process A sprint produces either a shippable product increment that can be delivered to customers or an internal deliverable. Internal deliverables, such as a product prototype, an architectural/design artifact, bug fixes… that enable future sprints. Sprint retrospective meeting: On completion of a sprint, team members meet to Discuss what went well during the sprint, what didn’t, and how the problems were tackled. Reflect on the effectiveness of the tools and methods used. The aim is to improve productivity in later sprints. Agile Software Engineering © Ian Sommerville 2018: 9  Key Scrum practices To be discussed next… Product backlog Timeboxed sprints Self-organizing teams Agile Software Engineering © Ian Sommerville 2018: 10  Product backlogs The product backlog is a list of what needs to be done to complete the development of the product. (a list of features + other) The items on this list are called product backlog items (PBIs), they should be estimated + prioritized. The product backlog may include: Product features to be implemented Essential development activities (prototype, architecture/design artifacts) Engineering improvements (refactoring, improving security/reliability) Product backlog items are initially described in broad terms without much details. User stories can be used to identify PBIs (to be discussed later). Example… Agile Software Engineering © Ian Sommerville 2018: 11  Example1: Product backlog items (Ilearn System) user story template: As a , I to 1. As a teacher, I want to be able to configure the group of tools that are available to individual classes. (feature, user story) 2. As a parent, I want to be able to view my children’ work and the assessments made by their teachers. (feature, user story) 3. As a teacher of young children, I want a GUI for children with limited reading ability. (feature, user story) 4. Assess current open source software to be used as a basis for parts of this system. (feature?) (development activity) 5. Refactor code to improve readability and maintainability. (feature?) (engineering improvement, no new functionality) 6. Implement encryption for all personal user data. (feature?) (engineering improvement, no new functionality) Agile Software Engineering © Ian Sommerville 2018: 12  Example2 Agile Software Engineering © Ian Sommerville 2018:  Product backlogs The Product Owner (team member) prioritizes the items in the Product Backlog and describes them to the team. The team determine which PBIs they can complete during the coming Sprint (top 3, top 4…). The team then moves PBIs from the Product Backlog to the Sprint Backlog. In doing so they expand each PBI into one or more Sprint Backlog tasks to include more details Operations that may modify the product backlog (before being moved to the Sprint Backlog)… next Agile Software Engineering © Ian Sommerville 2018:  Product backlog activities Refinement The PBIs are analyzed and refined to create more detailed PBIs. This may lead to the creation of new product backlog items. Estimation The team estimate the amount of work required to implement a PBI. Creation New items are added to the backlog. These may be new features suggested by the product owner, engineering improvements, or process activities. Prioritization The product backlog items could be reordered based on changed circumstances. Agile Software Engineering © Ian Sommerville 2018: 15 Operations that may modify the product backlog, e.g., a) PBI 1 has been split/refined into two items; b) PBI 2 and 3 have been estimated; c) PBI 6 has been added; d) PBI 4 and 5 have been re-prioritized Notice that the new item 6 has a higher priority than existing items 4 and 5. Agile Software Engineering © Ian Sommerville 2018: 16  PBI Estimation PBIs should have an associated estimate of how much effort is needed to implement them. The estimates help decide what goes into a sprint. It makes sense to assign a higher priority to the PBIs that deliver the most value for the least effort. (e.g., login) Effort required (estimation metric) E.g., person-hours or person-days. Story points (estimation metric) Story points are an arbitrary estimate of the effort involved in implementing a PBI They take into account the size of the task, its complexity, the technology that may be required and the ‘unknown’ characteristics of the work. Story points are estimated relatively. The team agree on the story points for a baseline task (well understood) and other tasks are estimated by comparison E.g., small/medium/large, [1 to 10] Agile Software Engineering © Ian Sommerville 2018: 17  PBI Estimation Effort estimation is hard, especially at the beginning of a project The team has little or no previous experience with the given type of work The used technologies are new to the team New team members Estimations are initially subjective → clearly not accurate Estimates usually improve with experience Scrum recommends a team-based estimation approach called “Planning Poker” → The rationale is that teams should be able to make better estimates than individuals Agile Software Engineering © Ian Sommerville 2018: 18  PBI Estimation: Planning Poker Each developer picks/hides a number estimating the level of difficulty All number are revealed at once Discussions… Each developer picks/hides a number estimating the level of difficulty All number are revealed at once Discussions …more rounds… Until there is a consensus or the average is adopted. The picked numbers are typically not 1, 2, 3, 4, 5,…. But Fibonacci numbers 1, 2, 3, 5, 8, 13, 21, 34, … (to prevent estimates from being too close to one another) Or just use easy/medium/hard (coarse) Agile Software Engineering © Ian Sommerville 2018: 19  Velocity Estimation After a number of sprints have been completed, it becomes possible for a team to estimate its “team velocity” → the sum of the estimates of the PBIs that could be completed during a sprint. For example, assume that PBIs are estimated in story points and, in consecutive sprints, the team implements 17, 14, 16, and 19 story points. The team’s velocity would be between 16 and 17 story points per sprint (the average). Velocity is used: To decide how many PBIs to include in a sprint For better planning As a measure of productivity Teams should try to refine how they work so that their velocity improves over the course of a project. Agile Software Engineering © Ian Sommerville 2018: 20  Sprint activities Sprint planning PBIs to be completed in that sprint are selected and, if necessary, refined to create a sprint backlog. This should not last more than a day at the beginning of the sprint. Sprint execution The team work to implement the sprint backlog items. If it is impossible to complete all of the sprint backlog items, the sprint is not extended. The unfinished items are returned to the product backlog and queued for a future sprint. Sprint reviewing (sprint retrospective) The work done in the sprint is reviewed by the team and (possibly) external stakeholders. The team reflect on what went well and what went wrong during the sprint with a view to improving their work process. Agile Software Engineering © Ian Sommerville 2018: 21  Sprint planning (first meeting) In a sprint planning meeting the team members collectively decide on the PBIs to be implemented during the sprint. The Product Owner leads the task of identifying the PBIs with the highest priority. When planning a sprint, the team do 3 things: Agree on a sprint goal: Features? Engineering activities? Code Improvements? When deciding on the features: key inputs are the PBIs estimates and the team’s velocity Create a sprint backlog (where user stories could be more detailed, maybe using use cases…). During a sprint, the team have daily meetings (scrums) to coordinate their work Agile Software Engineering © Ian Sommerville 2018: 22  Scrums (daily meeting) A scrum is a short, daily meeting that is usually held at the beginning of the day. During a scrum, all team members share information, describe their progress since the previous day’s scrum, problems that came up and plans for the coming day. This means that everyone on the team knows what is going on and, if problems arise, can re-plan short-term work accordingly. Scrum meetings should be short and focused. To discourage long discussions, they are sometimes organized as ‘stand-up’ meetings where there are no chairs in the meeting room. During a scrum, the sprint backlog is reviewed. Completed items are removed from it. New items may be added to the backlog as new information emerges. The team then decide who should work on which sprint backlog items that day. Agile Software Engineering © Ian Sommerville 2018: 23  Agile activities Unlike XP, Scrum does not dictate the technical agile activities that should be used. However, the following 2 practices are almost always used. Test automation Continuous integration Agile Software Engineering © Ian Sommerville 2018: 24  Sprint reviews (sprint retrospective, last meeting) At the end of a sprint, the team meets to: Review whether or not the sprint has met its goal. Discuss any new problems and issues that have emerged during the sprint. Reflect on how they can improve the way they work. The product owner has the ultimate authority to decide whether or not the goal of the sprint has been achieved. The code completeness checklist (next slide) helps assess whether the goal is met Agile Software Engineering © Ian Sommerville 2018: 25  Code Completeness Checklist Reviewed The code has been reviewed by another team member who has checked that it meets agreed coding standards, is understandable, includes appropriate comments, and has been refactored if necessary. Unit tested All unit tests have been run automatically and all tests have executed successfully. Integrated The code has been integrated with the project codebase and no integration errors have been reported. Integration tested All integration tests have been run automatically and all tests have executed successfully. Accepted Acceptance tests have been run if applicable (yet) and the product owner or the development team have confirmed that the product backlog item has been completed. Agile Software Engineering © Ian Sommerville 2018: 26  External interactions External interactions are interactions that team members have with people outside of the team. In Scrum, the idea is that developers should focus on development (without distractions) and only the ScrumMaster and Product Owner should be involved in external interactions. Team-focused: more staffing, special expertise… Product-focused: requirements, timing… Agile Software Engineering © Ian Sommerville 2018: 27  Project management There is a need for development teams to report on progress to company management (external interactions). A self-organizing team has to appoint someone to take on these responsibilities. In many companies the ScrumMaster has to take on such responsibilities. They are in the best position to provide accurate information on the project’s progress. Agile Software Engineering © Ian Sommerville 2018: 28