5719341
Descripción
Fichas por minal Kotwal, actualizado hace más de 1 año
|
Creado por minal Kotwal
hace más de 8 años
|
|
| Pregunta | Respuesta |
| Benefits of Scrum: * Higher productivity * Higher quality * Reduced time-to-market * Improved stakeholder satisfaction * Increased job satisfaction * More engaged employees | slide 7 |
| Important SCRUM (artefacts) documents: - Pre-execution agile gantt chart - Product backlog - User stories document - Sprint backlog - Burn down chart - Sprint planning notes - Sprint retrospective notes | Pre-cursor to starting Scrum: The Gantt chart - its important to create a Gantt chart representing your SCRUM processes - This is usually constructed during the project planning phase - Although, it is not fully suitable for agile projects, a gantt chart at planning stage will reveal a lot of imp info |
| - During the planning phase, the quality plan produces a test strategies which can used when testing. - There is no formal test plan documentation, but during the sprint planning meeting, it should be talked about - Agile gives a better opportunity to conduct testing processes, therefore UT can be performed during the sprint review meetings in order to get quick feedback from users - At the end of a sprint, the scrum master updated the burn down chart as a way to control the quality of delivering and the delivered product - The transition process from the development team to the maintenance team happens during the product deployment to the production environment - In this process the dev team will assist the maintenance team to understand the project configuration | next |
| Product backlog: - Requirements of the system, expressed as a prioritised list of backlog items - Managed and owner by the product owner - Spreadsheet (typically) - Usually created during the sprint planning meeting - Can be changed and re-prioritised | Estimation of the product backlog items: - Establishes team's velocity (how much effort a team can handle in one sprint) - Working out the units of complexity: size category, story points, work day/work hours - Methods of estimations: Expert review, creating a WBS |
| Backlog grooming: - Most product backlog items (PBI) need refinement bc they're too large and poorly understood - It's better to take a little time out of sprint execution - every sprint - to help prepare the product backlog for the next sprint planning meeting - in the backlog refinement meeting, the team estimates the amount of effort they would expend to complete items in the product backlog and provides other technical information to help the product owner to prioritise them | - Large vague items are split and clarified, considering both business and technical concerns. - Sometimes, a small part of the team with the product owner will compose and split the product backlog items before involving the entire team estimation - A skilled scrum master can help the team identify the small slices of work that still have business value, while also promoting a definition of "done" that includes proper testing and refactoring |
| - Agile also requires the ability to split the large epics into user stories representing very small product features - Since most customer don't use most features of products, it better to split epics to deliver the most valuable stories first - Delivering of low value feature later wil require for rework, but thats better than no work | What makes a product backlog good? - The PB should be available for anyone to see - The backlog must be the single source of requests. It's important for the source of requests to be centralised bc the entire list needs to be ordered - The PB is a living artefact and is never complete. its normal to identify new items, remove items, and to morph existing items. The product backlog lives for as long as the product lives |
| Common pitfalls: - It becomes tempting to use the backlog as a dumping ground of idea to satisfy stakeholders - Scrum guide suggests to spend no moee than 10% of your team's time keeping the backlog in working condition - Grooming the backlog makes sure that it always shows healthy characteristics that make it pleasure to work with. if proper grooming isn't done you will run into difficulty planning and delivery the backlog items | next |
| Product increment: - The increment (or the potentially shippable increment, PSI) is the sum of all the product backlog items completed ruing a sprint and all previous sprints - At the end of a sprint, the increment must be done under the Scrum team's definition of done - The increment must be in useable condition regardless of whether the product owner decides to actually release it | Definition of done (DoD) - This is the exit criteria to work out whether a product backlog item is complete - In many cases, DoD requires that all regression tests should be successful - The DoD may vary from one team to another, but should be consistent within one team |
| Burndown chart: - The sprint burn down chart is a publicly displayed chart showing the remaining work in the sprint backlog. - It's updated everyday, it gives a simple view of the sprint progress. - It also provides quick visualisation for reference | What happens if the team falls behind? - If the team notices that it's falling behind, as shown by the burn down charts * They should bring this fact to the Scrum master's attention - rather than hoping that they will eventually catch up without any corrective solution - If some amount of overtime isn't enough to the correct the problem * The scrum master should investigate the possibilities of adding temp team members |
| Supporting cast: - Scrum team may borrow from outside as well - often called supporting cast - Technical experts: Sometime the team needs the help of technical experts, such as build masters to set up their build scripts or an agile DBA to help design the test their database. - Technical experts are bought in on as needed, temp basic, to help the team vm overcome a difficult problem and to transfer their skills to one or more developers on the team | Domain experts: - The product will sometimes bring in domain experts to work with the team, perhaps a tax expert to explain the details of a requirement or the sponsoring executive to explain the vision of the project Independent tester: - Effective agile teams often have an independent test team working in parallel that validates their work throughout the lifecycle. |
| What if the team identifies an additional task? - If a new task introduces a delay in project completion or impacts the sprint, it must be entered into the sprint backlog by the scrum master, and treated like any other task - Confirmation of the new task may be requested of the product owner - The daily scrum isn't considered a problem solving session - It's a communication session - if there are issues that need more attention, interested parties should meet outside the daily scrum | next |
| Larger SCRUM teams: - In very large project, a larger team needs to be sub-divided into "smaller teams" - The best way to do is to work around tehe "architecture" of the system and each smaller team is responsible for its subsystem - Additional roles are introduced: * Architecture owner - leads their sub team through initial architecture envisioning for their sub-system * Integrator - responsible for building the entire system from its various sub-systems. These people often work closely with the independent test team, if there is one, who will want to perform system integrate testing regularly throughout the project | - In larger projects it isn't enough to focus on project leadership and allow self-organistion to manage the technical aspects of Project management. - Across the entire project the technical aspects of project management, such as dependency management, contract management, resource tracking, vendor management become important - The project management team is comprised of the team leaders from the different sub-teams - This team is likely to have short meeting every day called scrum of scrums where current status is shared and issues are identified |
| Sprint review meeting: - This comes after sprint execution - This meeting features a live demo, not a report - After the demo, the product owner reviews the commitments made at the sprint planning meeting and declared w which items they consider now done - Incomplete items are returned to the product backlog and ranked according to the product owner's revised priorities as c as candidates for future sprints | - External stakeholders, even end users, can attend this meeting - Good opportunity to inspect and adapt the product as it emerges, and iteratively refines everyone's understanding of the requirements - Many customer need to be able to react to a piece of functioning software to understand what they actually want. Iterative development allows the creation of products that couldn't have been specified up front in a plan driven approach |
| Sprint retrospective meetings: - Each sprint ends with a retrospective. - At this meeting the team reflects on its process, they think about their behaviour and take actions to adapt it to the future sprints - Dedicated scrum masters will find alternative to the fearful meetings everyone has come to expect. - An in depth retrospective requires an ev environment of psychological safety not found in most organisations. - Without safety, the retrospective discussion will either avoid the uncomfortable issues or deteriorate into blaming and hostility - A common impediment to full transparency on the team is the presence of people who conduct performance appraisals. | There are some extra meetings as follows; 1. backlog refinement 2. scrum of scrums |
| Scrum of scrums: - A technique to scale scrum up to large development groups, which allows clusters of teams to discuss their work, focusing specially on areas of overlap and integration - Each daily scrum within a sub team ends by designating one member as an ambassador to participate in a daily meeting with other ambassadors - Depending on the context, ambassadors may be technical contributors or each team's scrum masters | 4 questions are asked in these meetings: 1. What has your team done since we last met? 2. What will your team do before we meet again? 3. Is anything slowing your team down or getting in their way? 4. Are you about to put something in another team' way? |
| - Resolution of obstacles is expected sto focus on the challenges of coordination b/w the teams, negotiating responsibility boundaries - The scrum of scrums will track these working items via the backlog of its own, where each item contributes to improving between team coordination | next |
| Sashimi: - Scrum uses the sashimi technique to require that every slice of functionality created by the developer be complete - All of the requirements gathering and analysis, design work, coding, testing and documentation that constitutes a complete product are required to be completed in every sprint and must be visible in the sprint increment of functionality - When a stakeholder or the product owner sees the functionality demo-ed, they can assume that is it completed. - The product owner bases their view on this belief - When an increment is not complete, all incomplete must be identified and stored to the product backlog as incomplete work | next |
| Scrum but: - Is an exception to the "pure" scrum method, where a team has changed the method to adapt it to their own needs - not considered a good practice - Organisation that try to implement agile may turn to scrum. But unless they make the shift and become agile, implementing scrum won't let them achieve the success that agile is known for - such organisation implement scrum without agile are called scrum buts bc they're implementing scrum with tweaks |
¿Quieres crear tus propias Fichas gratiscon GoConqr? Más información.