Sindbad~EG File Manager
id,Title,Content,Excerpt,Categories,Featured
3437,Velocity,"The Velocity indicates the amount of value delivered in each sprint, enabling you to predict the amount of work the team can get done in future sprints. It is useful during your sprint planning meetings, to help you decide how much work you can feasibly commit to. The team's velocity can be estimated based upon the total estimate (for all completed stories) for each recent sprint. This isn't an exact science — looking at several sprints will help you to get a feel for the trend. For each sprint, the Velocity Chart shows the sum of the Estimates for complete and incomplete stories. Estimates can be based on story points, business value, hours, issue count, or any numeric field of your choice.
<img class=""size-full wp-image-3438 aligncenter"" src=""http://137.116.134.50/wp-content/uploads/2018/09/sg_velocity_20161014073347363.jpg"" alt="""" width=""1348"" height=""428"" />
<h1>Importance of velocity</h1>
Velocity is a key feedback mechanism for the Team. It helps the team to measure whether process changes it makes are improving its productivity or reducing it. While a Team's velocity will oscillate from Sprint to Sprint, over time, a well-functioning Scrum Team's velocity should steadily trend upward by roughly 10% each Sprint.
It also facilitates very accurate forecasting of how many stories a Team can do in a Sprint. For forecasting purposes, the average of the last three Sprint's Velocity should be used. Of course, this means it takes three Sprints of experience for a Team to determine its Velocity accurately, which can sometimes be difficult to explain to impatient stakeholders. Without Velocity, Release Planning is impossible. By knowing Velocity, a Product Owner can figure out how many Sprints it will take the Team to achieve a desired level of functionality that can then be shipped. Depending on the length of the Sprint, the Product owner can fix a date for the release.
The velocity metric is used to reconcile velocity changes - an increase in accepted bugs or chores can explain a dip in velocity. It’s also helpful for managing technical debt: keeping chores at a steady level ensures a focus on keeping your systems and code in peak condition. There are several things you can do with a velocity chart :
<ul>
<li>
<h4>Monitor overall project health</h4>
</li>
</ul>
<p style=""padding-left: 30px;"">The Velocity chart visualizes a number of project trends: iteration velocity (including average velocity), accepted stories by type, and volatility metrics. This makes the Velocity chart an ideal gut check for overall project health.</p>
<ul>
<li>
<h4>Understand velocity trends</h4>
</li>
</ul>
<p style=""padding-left: 30px;"">Accepted points may be low for a particular iteration when there is a large number of bugs, chores, or zero-point stories. The Velocity chart makes these “bug/chore walls” visible by showing iteration velocity dips alongside an increase in accepted bugs.</p>
<ul>
<li>
<h4>Track volatility</h4>
</li>
</ul>
<p style=""padding-left: 30px;"">Volatility is a relative measure of predictability. Frequent velocity peaks and valleys may imply an unpredictable project, whereas smoother iteration-by-iteration velocity suggests a more predictable one.</p>
<h1>Why do we need velocity?</h1>
<ul>
<li>Predict how much scope can be delivered by a specific date.</li>
<li>Predict a date for a fixed amount of scope to be delivered.</li>
<li>Understand our limits while defining the amount of scope we will commit for a sprint.</li>
</ul>
<h1>Can an incomplete user story be counted in velocity?</h1>
No, you shouldn't. Incomplete is undone. Velocity is about finished, delivered user stories. Here are some reasons why you shouldn't count incomplete user stories :
<ul>
<li>We can't really figure out how much is ready and how much is not; it will be a wild guess.</li>
<li>We may be led by a false sense of accuracy, due to the use of fractional numbers.</li>
<li>Incomplete means the user story still has no value for the customer.</li>
</ul>
<h1>Determining team velocity</h1>
An existing team can determine its velocity by completing the following steps :
<ul>
<li>Agree on a project iteration (for example, 10 workdays).</li>
<li>Gather a list of what the team completed in the previous 10 work days.</li>
<li>List the work completed in story points to establish their sum and the corresponding velocity value.</li>
<li>Plan to deliver this number of story points in the team's first iteration.</li>
</ul>
Add or remove points in the next iteration based on whether the team completes the targeted number of story points.
Most teams determine their baseline velocity within about three iterations.",,Monitor,
3439,Daily Stand-up,"In Scrum, on each day of a sprint, the team holds a daily Scrum meeting called the ""Daily Scrum.” Meetings are typically held in the same location and at the same time each day. Ideally, the Daily Scrum meeting is held in the morning as it helps to set the context for the coming day's work. These stand-up meetings are strictly time-boxed to 15 minutes. This keeps the discussion brisk but relevant.
The Daily Scrum is the key inspect and adapt meeting during a Sprint. It is designed to quickly inform everyone of what's going on across the team. It's not a detailed status meeting. The Daily Scrum tries to improve communication amongst team members, identifies and removes impediments to development, highlight and promote quick decision-making, and improves the team’s participation levels. The responsibility for conducting the Daily Scrum is with the Scrum Team. The Scrum Master facilitates the meeting. He/she ensures that all impediments faced by the team are noted and should get resolved. Moreover, the SM also coaches the Team to keep the Daily Scrum short and making sure that people speak briefly.
<img class=""size-full wp-image-3440 aligncenter"" src=""http://137.116.134.50/wp-content/uploads/2018/09/sg-daily-stand-up_20161017093228533.png"" alt="""" width=""1500"" height=""1350"" />
<h1><strong>Meeting </strong>Specifics</h1>
<h3><strong>Time-box:</strong></h3>
<ul>
<li>15 Minutes</li>
</ul>
<h3><strong>Attendees:</strong></h3>
<ul>
<li>Scrum Master</li>
<li>Product Owner (Optional)</li>
<li>Scrum Team</li>
</ul>
<strong>When:</strong>
<ul>
<li>It is held each working day at the same time and at the same place.</li>
</ul>
<h1><strong>How is the meeting held?</strong></h1>
The Daily Scrum meeting is not used as a problem-solving or issue resolution meeting. Issues are taken offline and usually dealt with by the relevant personnel after the meeting. During the Daily Scrum, each team member answers the following three questions :
<ul>
<li>What did you do yesterday?</li>
<li>What will you do today?</li>
<li>Are there any impediments in your way?</li>
</ul>
Or alternatively, as an advancement of traditional Scrum practice and/or market trends, each team member may explain :
<ul>
<li>How much of work has been completed by him/her in the sprint?</li>
<li>How much work is still remaining in the Sprint?</li>
<li>Does anything impede progress? If so what it is?</li>
</ul>
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 towards Sprint commitment. 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.
<h1><strong>Objective(s)</strong></h1>
The Daily Scrum Meeting is held so the team can self-organize and achieve its sprint commitment.
The objectives are :
<ul>
<li><strong>Team Sync:</strong> To review progress toward the Sprint goal.</li>
<li><strong>Assess Risks:</strong> To assess any risks to the Sprint commitment.</li>
<li><strong>Adjust Plan:</strong> To make any adjustments if required to the plan so the sprint commitment can be met.</li>
<li><strong>Accountability:</strong> The team should hold each other accountable for achieving their daily commitments.</li>
</ul>
<h1><strong>Key benefits</strong></h1>
<ul>
<li>The team stays in sync with how the project is going.</li>
<li>There is an opportunity for swift course correction if needed.</li>
<li>By consistently committing and delivering, trust is built among team members.</li>
<li>Action can be taken with those who are consistently unable to make their commitments (not always pleasant, but usually necessary).</li>
</ul>
<h1><strong>Suggestions</strong></h1>
<h3 style=""padding-left: 30px;"">Do's:</h3>
<ul>
<li><strong>Timebox your meeting duration:</strong> Without a specific time box in place, a Daily Scrum meeting can drag on and actually waste the time of the team. A typical daily meeting should get over in 15 minutes - but larger teams could agree upon a longer duration. The idea is to stop when that time runs out, and keep all discussions short and to the point.</li>
<li><strong>Start the meeting on time:</strong> Ensure that the Stand-up starts on time, even if some development team members are missing. A delay of even five minutes, when multiplied by the number of team members, counts for a lot of potential work wasted.</li>
<li><strong>Peer to peer interaction:</strong> All interactions should be on a peer-to-peer basis, and not in the form of a status report made to the Scrum Master. Teamwork is always emphasized in Scrum, and the team should communicate well with each other.</li>
<li><strong>Ask the 3 main questions and answer them:</strong> There are three questions that are sought to be asked and answered by each team member. What did you complete yesterday? What will you do today? Did you find any impediments in your way? Answers should be concise and precise.</li>
<li><strong>Stay focused:</strong> The Scrum Master must keep the team focused on answering the three main questions and prevent it from straying into random discussions. Each team member should focus on the meeting and not get distracted by phone calls or emails. This can extend the time box, or worse, remove the focus of the team from the meeting.</li>
</ul>
<h3 style=""padding-left: 30px;"">Don’ts :</h3>
<ul>
<li><strong>Don’t use it as a status reporting meeting:</strong> Apart from answering the three basic questions, the meeting should not be used to discuss other topics or problems even if they’re identified as impediments by the team members. The main purpose of the stand-up meeting is to make the team conversant about the sprint current progress and set the focus upon what work’s going to be done on that day.</li>
<li><strong>Don’t micromanage the meeting:</strong> The product owner, scrum master or any other team member should not micromanage the meeting. The stand-up should not be used as a venue for issuing instructions to team members or deciding how the team should carry out its work. Scrum teams are empowered to decide on their own how work should be taken up and completed. No efforts should be made to monopolize or dominate the meeting.</li>
<li><strong>Don’t remain seated during the stand-up meeting:</strong> As the name suggests, the entire team should remain standing during the Stand-up. The idea is to keep the team members on their toes so the meeting does not exceed the time box and they get charged up for the day’s work.</li>
<li><strong>Don’t hold the stand-up meeting away from the work location:</strong> With the exception of remote or distributed teams, the daily stand-up should be ideally held on or near the workplace or development room, preferably near the Scrum board. The idea is to keep the team charged up to tackle the day’s work and start with work immediately after the meeting. By holding the meeting away from the workplace, the team could lose its focus by engaging in other discussions while reaching the workplace.</li>
</ul>",,Scrum Events,
3445,Definition Of Ready,"It is a working agreement between the team and product owner on what readiness means. It is an input criteria to plan a story in a sprint. It is a way for a product owner to indicate an item in the product backlog as ready to work in a sprint. It is the accountability of product owner that there is a definition of ready defined. The scrum team can refuse to take an item into a sprint. The team makes explicit and visible the criteria (generally based on the INVEST matrix) that a user story must meet prior to being accepted into the upcoming iteration.
<h1>Definition of Ready Vs. Definition of Done</h1>
Many teams use the Definition of Done to check if a user story is finished and the product is ready to be delivered. But what about the user stories that a team receives from their product owner? Teams can check the quality of the user stories using a Definition of Ready. While the value of the Definition of Done (DoD) and Team Working Agreement has long been understood by serious agile teams, in my experience, the Definition of Ready (DoR) is one of the least utilized, yet more powerful tools an agile team can employ. While the DoR can be used for multiple artifacts and activities (Product Backlog, Sprint Review, etc), for new teams I prefer to start with a DoR for backlog item readiness, which introduces the concept into planning preparation, an important part of the work stream.
<h1>Definition of Ready for a User Story</h1>
<ul>
<li>User Story defined</li>
<li>User Story dependencies identified</li>
<li>User Story sized by Delivery Team</li>
<li>Scrum Team accepts User Experience artifacts</li>
<li>Performance criteria identified, where appropriate</li>
<li>The person who will accept the User Story is identified</li>
<li>The team has a good idea what it will mean to Demo the User Story</li>
</ul>
<h1>What are the benefits of a properly structured DoR?</h1>
<ul>
<li>Measure a backlog item’s “ready” state</li>
<li>Help the team identify when the product owner or another team member becomes overwhelmed</li>
<li>Keep the team accountable to each other</li>
<li>Reduce pressure on the team to commit to estimates before stories are “Ready”</li>
<li>Reduce “requirements churn"" in development</li>
</ul>
<h1>Definition of Ready for a Sprint</h1>
<ul>
<li>The Sprint Backlog is prioritized</li>
<li>The Spring Backlog contains all defects, User Stories and other work that the team is committing to</li>
<li>No hidden work</li>
<li>All team members have calculated their capacity for the Sprint</li>
<li>Full-time on project = X hours per day</li>
<li>All User Stories meet Definition of Ready</li>
</ul>
<h1>Why is Definition of Ready important?</h1>
Getting started with the poorly understood story can create many roadblocks for the scrum team. A story without proper information can lead to rework of work at best or work which takes the completely wrong direction at worst. It’s so clear that a user story has to meet a set of minimum criteria before it’s ready for inclusion in the work of the next sprint. This set of minimum criteria is the Definition of Ready and, like the Definition of Done, should be agreed upon by the Scrum team. This shared definition then allows the team to reject the stories that don’t have clearly defined acceptance criteria. It will save a lot of time if each user story meets Definition of Ready before the Sprint Planning meeting.
",,Monitor,
3449,Scrum Development Team,"<h1>What is the Scrum Development Team’s role?</h1>
A Scrum Team is a collection of individuals working together to deliver the requested and committed product increments. It comprises of cross-functional members who are capable of achieving the sprint goals. This could include software engineers, architects, programmers, analysts, system admins, QA experts, testers, UI designers, etc. The most effective scrum teams are tight-knit, co-located, and usually 5 to 7 members. Team members have different skill sets and cross-train each other so no one person becomes a bottleneck in the delivery of work. Strong scrum teams approach their project with a clear ""we"" attitude. All members of the team help one another to ensure a successful sprint completion.
<h1>Responsibilities of the Scrum Development Team</h1>
<h3 style=""padding-left: 30px;"">1. Core responsibilities</h3>
<ul class=""custom-padding-left-60"">
<li>Embraces the (5) Scrum Values – Focus, Commitment, Openness, Respect, and Courage.</li>
<li>Delivers working product on-time, on the scope and on quality.</li>
<li>Shares development responsibilities, assists, trains and mentors Team members to meet “Sprint” challenges.</li>
<li>Strives to value the individual and increase team recognition over self-recognition.</li>
<li>Builds consensus and applies sound judgment in a Team-centric environment.</li>
<li>Provides open and honest feedback within a “Scrum Team” environment.</li>
<li>Always prepared to challenge themselves and the Scrum Team in (DoD) “Definition of Done.”</li>
</ul>
<h3 style=""padding-left: 30px;""><strong>2.</strong> Sprint creation and implementation</h3>
<ul class=""custom-padding-left-60"">
<li>Select the tasks of highest need and complete them as quickly as possible.</li>
<li>Request clarification from the product owner when you are unclear about a user story.</li>
<li>Collaborate with other development team members to design the approach to a specific user story, seek help when you need it, and provide help when another development team member needs it.</li>
<li>Conduct peer reviews on one another’s work.</li>
<li>Take on tasks beyond your normal role as the sprint demands.</li>
<li>Fully develop functionality as agreed to in the definition of done.</li>
<li>Report daily on your progress.</li>
<li>Alert the scrum master to any roadblocks you can’t effectively remove on your own.</li>
<li>Achieve the sprint goal you committed to during sprint planning.</li>
</ul>
<h1>6 Qualities of Scrum Development Team</h1>
Key qualities in an ideal scrum team should be :
<p style=""padding-left: 30px;""><strong>1. Pair Programmer:</strong> The programmer should be able to work effectively with another one at one workstation. While one programmer writes the code - the driver - the other one observes - the navigator - and reviews each line of code as it is typed in. The two programmers switch roles frequently.</p>
<p style=""padding-left: 30px;""><strong>2. Understands TDD, BDD, etc. :</strong> The team member should be familiar with the advanced technique of using automated unit tests to drive the design of software and force decoupling of dependencies.</p>
<p style=""padding-left: 30px;""><strong>3. Understands Refactoring:</strong> Code Refactoring is the process of clarifying and simplifying the design of existing code, without changing its behavior. Scrum teams should maintain and extend their code a lot from iteration to iteration, and support continuous refactoring.</p>
<p style=""padding-left: 30px;""><strong>4. Continuous Integration:</strong> Continuous Integration (CI) involves producing a clean build of the system several times per day, usually with a tool like CruiseControl, which uses Ant and various source-control systems. Scrum teams typically configure CI to include automated compilation, unit test execution, and source control integration.</p>
<p style=""padding-left: 30px;""><strong>5. Self-motivated and organized:</strong> Scrum suggests self-organizing and self-managing teams. The Scrum team should remain accountable for the work it does and owns the projection behalf of the client. Self-motivation is an important Scrum virtue since all Scrum roles are empowered to function on their own and there is no senior-junior hierarchy within the team. The entire team is accountable for itself.</p>
<p style=""padding-left: 30px;""><strong>6. Team player:</strong> Scrum supports teamwork and not just individual efforts. It’s important to function as a single cohesive unit and achieve the goals by working together. Each team member should be a team player.</p>",,Scrum Roles,
3452,Product Backlog Refinement,"A product backlog is a prioritized list of work for the development team that is derived from the roadmap and its requirements. The most important items are shown at the top of the product backlog so the team knows what to deliver first. The Product Owner creates, maintains, and regularly re-orders the Product Backlog. The Product Owner uses the Product Backlog to adapt to emerging requirements, customer feedback, and market changes.
<h1>What is product backlog grooming or refinement?</h1>
A backlog is defined as the full set of user stories not in the current sprint that defines the remainder of the project's scope. Left unattended, the list of individual items on a product backlog can quickly become overwhelming to any development team. When that happens, the status of individual user stories can become unclear, the team can lose focus on important tasks and they may have trouble estimating the time and resources needed to complete items, and the project completion date can slip. The backlog grooming meeting is attended by the team, the Product Owner, and the Scrum Master. During the meeting, everyone works together to prepare the backlog for the next sprint planning meeting. This might include adding new stories and epics, extracting stories from existing epics, and estimating effort for existing stories.
<img class=""size-full wp-image-3453 aligncenter"" src=""http://137.116.134.50/wp-content/uploads/2018/09/sg-product-backlog-refinement_20161017101427752.png"" alt="""" width=""800"" height=""622"" />
<h1>The objective of Product backlog grooming</h1>
A well-maintained backlog will prevent sprint planning meetings from lasting an unnecessarily long time. If scrum product backlog items are written with clearly defined acceptance criteria and estimated by the appropriate team members, the planning process won't be stalled with work that could have been accomplished prior to the meeting.
Time should be dedicated towards product backlog maintenance to ensure that this preliminary planning always occurs. It also renders lengthy, even tense conversations about estimation, prioritization, etc. irrelevant. In all, product backlog grooming offers the team a chance to discuss stories and modify them in advance of the planning meeting. It might be hard for a team to pull away from its work mid-sprint, but this preventative maintenance will help keep your sprint planning meetings productive and to-the-point.
<h1>Why is product backlog grooming important?</h1>
<ul class=""custom-padding-left-30"">
<li>Increases efficiency of the team by greatly reducing uncertainty and unknowns.</li>
<li>Better refined stories are more accurately estimated, more accurately tested, and more accurately implemented.</li>
<li>Increases efficiency of the team due to the benefit of shared knowledge gained by the entire Scrum team being in the refining.</li>
<li>Allows the team to maintain a sustainable, higher pace.</li>
<li>When done well, refining greatly reduces the time required for a Sprint Planning meeting.</li>
</ul>
<h1>Tip for effective Backlog grooming</h1>
<ul class=""custom-padding-left-30"">
<li>Try to never schedule backlog refinement during the first or last 20% of the Sprint.</li>
<li>Treat the backlog refinement meeting just like the first part of the Sprint Planning Meeting.</li>
<li>Make sure the PO knows that, during all of this sprint's backlog refinement sessions, they will be expected to present enough work to last about 2 Sprints *beyond* the current sprint.</li>
<li>The backlog items should be fine-grained and well understood by the PO or a Dev Team member for this meeting to work well. Try to have an initial set of acceptance tests defined before the meeting occurs.</li>
<li>Make sure everyone understands that estimates are not final until a PBI has been accepted into a sprint.</li>
<li>Make sure everyone understands that Product Backlog order is not final until a PBI has been accepted into a sprint.</li>
<li>Keep your eye on the goals of the meeting.</li>
<li>Assign action items for any big risks or unknowns.</li>
<li>Remember that backlog item (and/or User Stories) are a collaboration between the PO and the Dev Team.</li>
<li>Remind the Dev Team to review the PBI's to be discussed 24 hours prior to the refinement session.</li>
<li>Definitely feel free to split PBI's during this meeting.</li>
<li>Optimize your time in the meeting.</li>
<li>Don't be afraid to discuss a couple of items that are farther down the backlog.</li>
<li>Strongly consider doing some informal backlog refinement before the full team backlog refinement.</li>
<li>Don't be afraid to introduce late breaking PBI's. Try to minimize them, but embrace them when they happen.</li>
<li>Meeting Attendees: The entire Scrum Team + rare appearances by other key people.</li>
<li>Experiment with the amount of refinement that your team does.</li>
<li>Be sure to retrospect, inspect, and adapt!</li>
</ul>
",,Scrum Events,
3461,Product Backlog,"A product backlog is a prioritized list of work for the development team that is derived from the roadmap and its requirements. The most important items are shown at the top of the product backlog so the team knows what to deliver first. The Product Owner creates, maintains, and regularly re-orders the Product Backlog. The Product Owner uses the Product Backlog to adapt to emerging requirements, customer feedback, and market changes.
<h1>What are the Product Backlog Items?</h1>
The product backlog is composed of product backlog items or PBIs. Most PBIs are featured, items of functionality that will have tangible value to the user and customer. These are often written as user stories (or sometimes use cases or free-form tests). Other PBIs include defects needing repair, technical improvements, knowledge-acquisition work, and any other work the product owner deems valuable. The figure below illustrates the product backlog.
<img class=""size-full wp-image-3465 aligncenter"" src=""http://137.116.134.50/wp-content/uploads/2018/09/sg-product-backlog_20161017102326244.png"" alt="""" width=""3313"" height=""3200"" />
<h1>PBI types</h1>
The product backlog items can be categorized mainly into four fundamental types :
<ul class=""custom-padding-left-30"">
<li><strong>Feature:</strong> The most common type of PBI is something that is of value to a user or customer - the product features. It can be a brand-new functionality or changes to existing functionality. Features, for most teams, should represent the bulk of items in the backlog.</li>
<li><strong>Defects:</strong> Some teams like to include defects/bugs in their product backlog. High-performance agile teams never let defects live long so they are unlikely to ever have many defects in their product backlogs.</li>
<li><strong>Technical Work:</strong> PBIs can also include technical items. Examples might include upgrading to the latest version of the Oracle DBMS or refactoring a section of previously completed code.</li>
<li><strong>Knowledge Acquisition:</strong> Another type of PBIs are items that involve knowledge acquisition. During agile development when the team is presented with a high degree of uncertainty a common and effective solution is to research information. Examples include prototype, proof-of-concept, research, experiment, spike, etc.</li>
</ul>
<h1>Creating and maintaining the Product backlog</h1>
The backlog needs regular attention and care - it needs to be managed carefully. At the start of the project, the Scrum Team and its Product Owner start by writing down everything they can think of easily. This is almost always more than enough for a first sprint.
After this initial setup, the Product Backlog has to be maintained in an ongoing process that comprises the following steps :
<ul class=""custom-padding-left-30"">
<li>Ordering the Scrum Product Backlog, The most important items are moved to the top.</li>
<li>Preparing the high-priority entries for the next Sprint Planning Meeting.</li>
<li>(Re-)Estimating the entries in the Scrum Product Backlog.</li>
</ul>
The Product Owner is responsible for making sure that the Product Backlog is in good shape. This is a collaborative process. When using the Scrum Framework about 10% of the Scrum Team’s total time should be reserved for maintaining the Product Backlog (discussion, estimation etc.). The collaborative maintenance of the Product Backlog helps to clarify the requirements and create a buy-in from the Scrum Team.
<h1>Characteristics of a good Product Backlog</h1>
Good product backlogs share similar characteristics - DEEP: Detailed appropriately, Emergent, Estimated, and Prioritized.
<ul class=""custom-padding-left-30"">
<li><strong>Detailed Appropriately:</strong> The product backlog items will differ in their level of detail. Those that we will work on sooner, those at the top of the product backlog, will be more detailed. Those that we won't work on or for some time will be less detailed. We want to refine (add detail to) backlog items as they rise in priority, adding details in a just-enough, just-in-time fashion.</li>
<li><strong>Emergent:</strong> As discussed in earlier chapters, the product backlog is a living document, constantly changing as the product is being developed or maintained. As the team and product owner learn more about the product and the marketplace, they might add new items, discard some, and change others. The emergent nature of the product backlog is not only expected but is a sign of a healthy and functioning product backlog.</li>
<li><strong>Estimated:</strong> Each product backlog should have a size estimate that corresponds to the effort required to develop that item. The product owner uses these estimates to help determine a product backlog item's priority. Ideally, most of the items at the top of the product backlog will be sprint-sized, small enough to be worked on during a single sprint. Large, high-priority items should be broken into smaller stories prior to being declared sprint-ready (see Definition of Ready for more on this concept).</li>
<li><strong>Prioritized:</strong> A product backlog should be a prioritized list of PBIs, but not every PBI needs to be prioritized. I recommend prioritizing about a release worth of PBIs. Prioritizing beyond that is likely a waste of effort, as too much might change by the time the first release is out. Instead, prioritize new items as they emerge and save the ""someday"" or ""future release"" items for later.</li>
</ul>
",,Scrum Artifacts,
3464,Scrum Master,"<h1>What is the scrum master’s role?</h1>
The Scrum Master is responsible for making sure a Scrum team lives by the values and practices of Scrum. He/she is often considered a coach for the team, helping the team do the best work it possibly can. The SM can also be thought of as a process owner for the team, creating a balance with the project's key stakeholder, who is referred to as the product owner. The Scrum Master does everything possible to help the team perform at their highest level. This involves removing any impediments to progress, facilitating meetings, and doing things like working with the product owner to make sure the product backlog is in good shape and ready for the next sprint. The Scrum Master's role is commonly filled by a former project manager or a technical team leader but can be anyone.
Main role activities carried out by a Scrum Master include :
<ul>
<li>He/she is a facilitator and Servant Leader who encourages and demands self-organization from the development team.</li>
<li>He/she enables close cooperation across all roles and functions, addresses resource issue and disobedience of Scrum practices.</li>
<li>He/she protects the team from external and internal distractions.</li>
<li>He/she removes impediments so the team can focus on the work at hand and follow scrum practices.</li>
<li>He/she is not typically a manager or lead, but he is an influential leader and coach who does not do direct command and control.</li>
</ul>
<h1>Responsibilities of the Scrum Master</h1>
<h3>Facilitation of Scrum events</h3>
The Scrum Framework defines several meetings that have to be organized and facilitated by the Scrum Master :
<ul>
<li>Daily Scrum Meetings</li>
<li>Sprint Planning Meetings</li>
<li>Sprint Review Meetings</li>
<li>Sprint Retrospective Meeting</li>
</ul>
<h3>Maintain team dynamics</h3>
<ul>
<li>Coaching team members (e.g. with one-on-one coaching).</li>
<li>Mediating through conflicts.</li>
<li>Helping the team to make decisions.</li>
<li>Fostering the developer team’s self-organization.</li>
<li>Mediating the general conflict of goals between the development team (high technical quality) and product owner (more features).</li>
</ul>
<h3>Support learning</h3>
<ul>
<li>Continue learning and being Agile (e.g. visit user groups, attend conferences, read books, write blogs, etc.).</li>
<li>Helping the team to create information radiators.</li>
<li>Giving feedback to the team.</li>
<li>Encouraging the use of Agile Engineering Practices within the development team (e.g. one click releases, continuous delivery, feature flags, etc.).</li>
</ul>
<h3>Help in product-related activities</h3>
<ul>
<li>Helping to write or split user stories.</li>
<li>Helping to write or adapt product visions.</li>
<li>Helping to order product backlog items.</li>
<li>Helping with the release planning.</li>
<li>Being familiar with the team’s work (i.e. the product).</li>
</ul>
<h3>Supporting the big picture</h3>
<ul>
<li>Bringing people together who should talk to each other.</li>
<li>Keeping in touch with every stakeholder regularly.</li>
<li>Helping the team to report to management.</li>
<li>Helping to further the Agile community within the organization.</li>
<li>Sharing insights throughout the company (micro-blogging, blogging, internal conferences, etc.).</li>
<li>Being a contact person for everyone on the team and their stakeholders regarding Agile.</li>
<li>Giving learning opportunities to people in the organization (e.g. talks or workshops) and letting them learn important Agile concepts like e.g. technical debt.</li>
</ul>
<h3>Facilitating change</h3>
<ul>
<li>Helping the team to get rid of impediments.</li>
<li>Suggesting new metrics for the team as catalysts for change.</li>
</ul>
<h3>Mirror</h3>
<ul>
<li>Reflecting Agile and Scrum values to the team.</li>
<li>Reminding the team of their arrangements (e.g. policies).</li>
<li>Helping the team to continuously improve their process.</li>
<li>Reflecting issues to the team through observation from outside of the team.</li>
<li>Asking open questions.</li>
<li>Checking the artifacts used by the team (e.g. Sprint backlog, metrics, etc.).</li>
</ul>
<h3>Miscellaneous</h3>
<ul>
<li>Helping the team to keep focus (e.g. by acting as a buffer between external distractions and the team).</li>
<li>Helping the team to maintain their Scrum tools (Storyboard, Action board, charts, backlogs, etc.).</li>
<li style=""text-align: left;"">Helping team and product owner to find a suitable:- Definition of Done “DoD”.</li>
</ul>
<p style=""padding-left: 30px;""> - Definition of Ready.</p>
<h3>Scrum Master Skills</h3>
A Scrum Master is usually the team leader or the project manager. A scrum master should ideally have a good balance of the following skills :
<ul>
<li>Technical expertise</li>
<li>Understands the Product Owner's Vision</li>
<li>A good team player and Mentor</li>
<li>Understands the team's capabilities</li>
<li>Motivating and coaching the team</li>
<li>Problem solver</li>
</ul>
<h1>6 Qualities of Scrum master</h1>
<h3 style=""padding-left: 30px;"">1. Responsible</h3>
<p style=""padding-left: 30px;"">A Scrum Master’s role is an important one in Scrum. He/she ensures that the team follows Scrum in a proper manner and is responsible for facilitating the work process so the team can deliver successful product increments.</p>
<h3 style=""padding-left: 30px;"">2. Humble</h3>
<p style=""padding-left: 30px;"">One of the best ways of gaining the respect of people is to be humble and remain true to work. The SM should play a servant-leader role and talk humbly with people and make genuine efforts to understand their problems and resolve them.</p>
<h3 style=""padding-left: 30px;"">3. Collaborative</h3>
<p style=""padding-left: 30px;"">SM should be helpful and willing to share ideas and thoughts. He/she should ideally play a servant-leader role and communicate positively with the team members to understand their problems and issues and do his/her level best to remove the impediments faced by the team.</p>
<h3 style=""padding-left: 30px;"">4. Committed</h3>
<p style=""padding-left: 30px;"">Being an SM is not easy – it is generally a full-time job and requires a lot of efforts. The SM should remain committed to the team in terms of being available whenever he/she is needed, able to understand the team members and help them effectively deal with their problems as and when they arise.</p>
<h3 style=""padding-left: 30px;"">5. Influential</h3>
<p style=""padding-left: 30px;"">The SM bridges the gap between the Scrum team and the management. At times he/she might be required to negotiate for better working conditions or quick resolutions to problems with the management. The SM should be influential and able to convince the management so issues can be resolved quickly.</p>
<h3 style=""padding-left: 30px;"">6. Knowledgeable</h3>
<p style=""padding-left: 30px;"">The SM also functions as a mentor and coach for the team. He/she should be conversant with the latest trends and updates in Scrum and share them with the team. The SM should be knowledgeable about Scrum topics.</p>
",,Scrum Roles,
3471,Sprint Backlog,"Within the Sprint Backlog, all activities required to complete the committed entries from the Scrum Product Backlog are stored. All entries have to be estimated on a person-hour base in order to track progress and remaining efforts.
The Sprint Backlog is a living artifact and is updated on a daily base. If a team member starts to work on an activity his name is recorded within the sprint backlog. New activities can be added to the Sprint Backlog during the Sprint. At the end of the day, all remaining efforts are updated and this defines how much work is left until the Sprint Goal is reached. The Definition Of Done is used to decide if an item is done or not.
<h1>How to create a sprint backlog?</h1>
The Sprint Backlog is created during the Sprint Planning Meeting. The team pulls the amount of work they want to do from the Product Backlog into the Sprint Backlog and further decomposes the PBIs into Sprint Tasks. The team decides the how and expresses this in the tasks. The best way to represent the Sprint Backlog is a physical task board, using PostIt Notes or index cards as well be kept electronically within e.g. an Excel-Sheet or digital task board. The latter has some advantages (e.g. transparency and easy access) but add additional complexity if the Scrum Team is distributed over multiple sites. The figure below shows an example of how such a task board could be organized. The structure should be adapted to reflect the needs of the project.
<h1>Why is sprint backlog Important?</h1>
It is common practice in Scrum that the Sprint Backlog is represented on a Scrum board or task board, which provides a constantly visible depiction of the status of the User Stories in the backlog. Also included in the Sprint Backlog are any risks associated with the various tasks. Any mitigating activities to address the identified risks would also be included as tasks in the Sprint Backlog. Once the Sprint Backlog is finalized and committed to by the Scrum Team, new user stories should not be added – however, tasks that might have been missed or overlooked from the committed user stories may need to be added. If new requirements arise during a Sprint, they will be added to the overall Prioritized Product Backlog and included in a future Sprint.
<h1>9 Tips for Creating a Good Sprint Backlog</h1>
<ul class=""custom-padding-left-30"">
<li>Involve every team member in the process.</li>
<li>Discuss how every item should be implemented.</li>
<li>Have a definition of done.</li>
<li>Identify all kinds of tasks.</li>
<li>Don't estimate tasks at all.</li>
<li>Don't assign tasks up front.</li>
<li>Review the sprint commitment.</li>
<li>Don't use too much time.</li>
<li>Evolve the Sprint Backlog during the sprint.</li>
</ul>
",,Scrum Artifacts,
3476,Product Owner,"<h1>What is the product owner’s role?</h1>
A product owner is a person who represents the customer, business or user community and is responsible for working with the team to determine what features will be included in the product release. As a liaison between the development team and customers, the product owner must collaborate closely with both groups to ensure there is a clear understanding of what features are needed in the product or application. Because there may be a variety of types of customers and users, the product owner must have a firm understanding of the business domain and the varying needs of different types of users.
The product owner role requires an individual with certain skills and traits, including availability, business savvy, and communication skills. First, the Scrum product owner should remain available to the team. The best product owners show commitment by doing whatever is necessary to build the best product possible – and that means being actively engaged with their teams.
Business savvy is important for the agile product owner because he or she is the decision maker regarding what features the product will have. That means, the agile PO should understand the market, the customer and the business in order to make sound decisions.
Finally, communication is a large part of the product owner responsibilities. The product owner role requires working closely with key stakeholders throughout the organization and beyond, so he or she must be able to communicate different messages to different people about the project at any given time.
The Product Owner is the visionary of the project and is responsible for :
<ul>
<li>Gathering requirements</li>
<li>Managing and prioritizing the Product Backlog</li>
<li>Software acceptance</li>
<li>Planning the release</li>
<li>Understand the value of the project</li>
</ul>
<h1>Skills of Product Owner</h1>
A product owner is usually a CEO, a Domain Specialist, a Project Manager or even a Business Analyst with technical skills. A Product Owner should ideally have a good balance of the following skills :
<ul>
<li>Domain expertise</li>
<li>Good technical knowledge</li>
<li>A decision maker</li>
<li>Easily available to the team</li>
</ul>
<h1>Responsibilities of the Product Owner</h1>
The Product Owner decides what will be built and in which order. He or she will :
<h3>Manage Product Backlog and Release Planning</h3>
<ul>
<li>Define the features of the product or desired outcomes of the project.</li>
<li>Adjust features/outcomes and priority as needed to ensure ROI.</li>
<li>Fully elaborates Acceptance Criteria for User Stories.</li>
<li>Prioritize User stories according to business value.</li>
<li>Perform Release planning and ensures that the release backlog is aligned with the Vision and Roadmap.</li>
<li>Reviews backlog in depth with the Scrum Master in preparation for future Release Planning activities.</li>
<li>Write new User Stories needed in order to have a complete and comprehensive backlog.</li>
</ul>
<h3>Work closely with the Scrum Team</h3>
<ul>
<li>Collaborates with the team to ensure User Stories are accurately elaborated and understood.</li>
<li>Ensures that everyone in the Scrum Team understands what is required.</li>
<li>Be available to answer any question arise during Sprint execution and support them.</li>
</ul>
<h3>Sprint Planning and Execution</h3>
<ul>
<li>Attends Sprint Planning in order to answer any remaining questions.</li>
<li>Attends Daily Stand-ups to remain engaged and up-to-date on the team’s progress.</li>
<li>Completes incremental reviews of stories as they are completed.</li>
<li>Adjust priorities of stories mid-sprint based on impediments or dependencies.</li>
<li>Attend the Demo to provide feedback and acceptance of stories.</li>
<li>Accept work results.</li>
</ul>
<h3>Stakeholder Management</h3>
<ul>
<li>Collaborates with Stakeholders outside of the team to review progress.</li>
<li>Collect and discuss required functionalities with the different Stakeholders. These requirements are then combined and filtered before giving it to the team in the form of prioritized Scrum Product Backlog Items.</li>
</ul>
<h1>5 Qualities of the product owner</h1>
<h3 style=""padding-left: 30px;"">1. Leadership</h3>
<p style=""padding-left: 30px;"">As every team member is responsible for the product success, It is must for the product owner to provide guidance and direction to everyone involved in the development effort and ensures that the project goes well.</p>
<h3 style=""padding-left: 30px;"">2. Decision making</h3>
<p style=""padding-left: 30px;"">He or she should be a good decision maker especially in deciding which product features will bring the highest ROI.</p>
<h3 style=""padding-left: 30px;"">3. Communication</h3>
<p style=""padding-left: 30px;"">He/she must be able to communicate different messages to different people about the project at any given time.</p>
<h3 style=""padding-left: 30px;"">4. Serve</h3>
<p style=""padding-left: 30px;"">Adopt a “customer service” mentality, make yourself available in-person whenever possible, and be open to questions.</p>
<h3 style=""padding-left: 30px;"">5. Let Go</h3>
<p style=""padding-left: 30px;"">Allowing the Scrum team to oversee their own task-execution will save time and make everyone’s life easier.</p>
",,Scrum Roles,
3478,Sprint Review Meeting,"A Sprint Review/Demo meeting is held at the end of the Sprint to inspect the Increment. The Team demonstrates the Increment with focus on the Sprint Goal according to the Definition of Done. The Product Owner reviews and accepts the delivered Increment.
<h1>Meeting Specifics</h1>
<h4 style=""padding-left: 30px;"">Time-box :</h4>
<ul class=""custom-padding-left-30"">
<li>1.5 hours (2 weeks sprint) / 3 hours (4 weeks sprint)</li>
</ul>
<h4 style=""padding-left: 30px;"">Attendees :</h4>
<ul class=""custom-padding-left-30"">
<li>Scrum Master</li>
<li>Product Owner</li>
<li>Scrum Team</li>
<li>Stakeholder and Sponsors</li>
<li>Customer</li>
</ul>
<h1>How is the meeting held?</h1>
The development team presents the results of the Sprint. The Product Owner reviews and accepts the delivered product increment. During the Sprint Review Product Owner, Development Team and stakeholders review what was done. Typically this takes the form of a demo of the new features. The Scrum Team goes through the forecasted Product Backlog items and reviews how the requirements (user stories) have been realized in the product increment.
After the demonstration, the Product Owner and other relevant stakeholders tell their impressions and clarify their requirements (user stories) if a requirement was not implemented right. The Product Owner identifies what has been done and what hasn't been done (according to the Definition of Done). The Product Owner accepts the user stories that have been done.
Results of this meeting can be new requirements in the Product Backlog, and a new prioritization of existing Product Backlog items.
<h1>What are the objectives of the Sprint Review Meeting?</h1>
The purpose of the meeting is for the team to show the customers and stakeholders the work they have accomplished over the sprint. The meeting is facilitated by the product owner but it is not uncommon to have the team members run the meeting. In this meeting, the customers (PO) should review the following data :
<ul class=""custom-padding-left-30"">
<li>The work committed by the team</li>
<li>The actual work completed by the team</li>
<li>Key decisions made during the iteration/sprint (this may include technical, market-driven, requirements, etc.,)</li>
<li>Project metrics (code coverage, etc.)</li>
<li>Demo of the work itself</li>
<li>Priority review (for the next iteration/sprint)</li>
</ul>
<h1>What should be the focus in Sprint Review Meeting?</h1>
<ul class=""custom-padding-left-30"">
<li>The Scrum Master should make sure the sprint review is about the process or the product or product increment, not about people.</li>
<li>Stakeholders should operate as a team, rather than as individual subject matter experts.</li>
<li>The product owner should encourage the team to maintain a steady pace during the product walk-through.</li>
<li>The product owner should avoid the temptation to formulate solutions. The team should formulate and agree on possible solutions.</li>
<li>The product owner and Scrum Master should focus the review on the product or product increment presented and not drift into the discussion of other products or areas.</li>
</ul>
<h1>Tips for holding the Sprint Review Meeting</h1>
<h3 style=""padding-left: 30px;"">1. Let everyone know why there’s a Sprint Review</h3>
<p style=""padding-left: 30px;"">Start by making sure that everyone, including the stakeholders, knows the reason for the Sprint Review – that is, it’s a collaborative working session where the team will showcase its work and everyone will look at the working software produced during the Sprint.</p>
<h3 style=""padding-left: 30px;"">2. Send a team reminder</h3>
<p style=""padding-left: 30px;"">Remind the team before Sprint Planning that there will be a Review at the end of the Sprint and describe what to expect. The team should be able to show :</p>
<ul class=""custom-padding-left-30"">
<li>An overview of how the Sprint went</li>
<li>The “done” items as working software</li>
<li>Which items are not done and that they’re now back on the Product Backlog. This is designed to ensure that no hidden work is undone (technical debt)</li>
</ul>
<h3 style=""padding-left: 30px;"">3. Ask the team how it’ll showcase its work</h3>
<p style=""padding-left: 30px;"">The team should consider ways and methods how it can best showcase the completed work. It could consider demonstrating relevant subsets of acceptance tests collectively, or alternatively, each team member could volunteer to demonstrate one User Story each.</p>
<h3 style=""padding-left: 30px;"">4. Help the team prepare</h3>
<p style=""padding-left: 30px;"">The team should take the ownership of the work it’s responsible for. Leaders should step aside and help the team to self-organize by facilitating the process.</p>
<p style=""padding-left: 30px;"">The Scrum Master should ask questions such as :</p>
<ul class=""custom-padding-left-30"">
<li>What does the success of the Review look like?</li>
<li>What’s the next step?</li>
<li>How will we know we’ve achieved that?</li>
</ul>
<h3 style=""padding-left: 30px;"">5. The Product Owner should educate him/her self</h3>
<p style=""padding-left: 30px;"">The Product Owner should :</p>
<ul class=""custom-padding-left-30"">
<li>Understand each User Story properly.</li>
<li>Be clear on the acceptance criteria.</li>
<li>Able to ask meaningful questions.</li>
<li>Be ready to discuss the Product Backlog as it currently stands including what the next highest priority items are.</li>
<li>He/she could also use this meeting as an opportunity to remind the team of the Release Goal.</li>
<li>Remembering the big picture can be immensely valuable.</li>
</ul>
<h3 style=""padding-left: 30px;"">6. Watch the clock!</h3>
<p style=""padding-left: 30px;"">It amazing to know that many companies use a time-boxed framework like Scrum but still don’t have a wall clock in the meeting room! A clock should be made available if it’s not there in the working room.</p>
<h3 style=""padding-left: 30px;"">7. Respecting the time box</h3>
<p style=""padding-left: 30px;"">A self-organizing team should open the meeting with a quick check-in round where everyone quickly says how they’re feeling and what’s on their minds. The team should outline the aim of the meeting on a whiteboard and start with the proceedings as soon as possible. The meeting is time-boxed so every minute counts for the team.</p>
<h3 style=""padding-left: 30px;"">8. Make time to discuss the next move</h3>
<p style=""padding-left: 30px;"">The Product Owner should be able to discuss the Product Backlog as it currently stands and then invites open discussions about whether it is what the team should do next. Is there a more optimal way? If so, how can the team measure this? Ultimately, the Product Owner has the final call, but anyone with a vested interest in the project should be present as this is a great opportunity for discussion.</p>
<h3 style=""padding-left: 30px;"">9. Record the results</h3>
<p style=""padding-left: 30px;"">Don’t forget to record the main points of what was agreed.</p>
",,Scrum Events,
3483,Scrum Roles,"<h1>The Scrum Framework defines three roles:</h1>
<p style=""padding-left: 30px;"">1. <strong>Product owner</strong> holds the vision for the product</p>
<p style=""padding-left: 30px;"">2.<strong> Scrum Master </strong>helps the team best use Scrum to build the product</p>
<p style=""padding-left: 30px;"">3. <strong>Development</strong> team builds the product</p>
These three Scrum roles are co-equal and all of them have certain responsibilities.
<h1>The Product Owner – Responsible for the project and business value</h1>
The product owner is the cornerstone of project success, responsible for defining the work that needs to be completed and prioritizing that work. He or she needs to know what the project is expected to deliver and why those elements are important - to customers, to the market, to the organization. The product owner must also act as an expert guide and provide valuable suggestions as the team carries out the project. He/she remains actively involved throughout the Project execution, Reviews and Reprioritization based on shifting needs and ongoing feedback. The changes in priorities and feature design should be properly communicated and explained to the team by the product owner.
The PO’s entire focus is on ensuring that the work done by the team aligns with product vision and strategy. A product owner should be self-disciplined and avoid micromanaging the team's activities. He or she is assisted by the Scrum Master.
Read more about the <span style=""color: #3366ff;""><a style=""color: #3366ff;"" href=""https://www.quickscrum.com/ScrumGuide/180/sg-Product-Owner"" target=""_blank"" rel=""noopener""><u>Product Owner</u></a>’s</span> role.
<h1>The Scrum Master – Facilitates Scrum and removes impediments</h1>
The Scrum Master role has two distinct parts.
First, he or she acts as the protector of the team, making sure that everyone on the project, especially the development team members, can focus on their work without any distractions. Some of those distractions may be directly associated with the work - for example, the product owner who oversteps the boundaries and starts to dictate the work approach to the team. The Scrum Master may need to protect the team from organizational disruptions or internal distractions - for example, arranging to replace problematic computers or providing a less noisy work area.
Second, He or she will ensure that the product owner and development team stay within the Scrum framework. The Scrum Master is the expert on how Scrum works and how it should be applied. The Scrum Master can also coach the team members on how to use Scrum in the most effective manner.
Read more about the <span style=""color: #3366ff;""><a style=""color: #3366ff;"" href=""https://www.quickscrum.com/ScrumGuide/179/sg-Scrum-Master"" target=""_blank"" rel=""noopener""><u>Scrum Master</u></a>’s</span> role.
<h1>The Development Team – Develops the product</h1>
A typical Scrum development team consists of five to nine skilled people and generally includes the typical functional roles required to complete the project. In software development, it means architects, testers, developers, and designers; but those titles are only relevant in establishing each individual's expertise.
The team acts collectively to determine how to achieve its goals. The specific features it works on are determined by the priority established by the product owner. The work done by the team is guided by the Scrum process and monitored by the Scrum Master. Everything else is up to the team to manage. Each team member can take a feature from the prioritized sprint backlog, then decide individually how to execute the work.
This level of autonomy is a cornerstone of Scrum. It encourages strong bonds between team members and helps create a positive working environment. While the idea of a team exists in Waterfall projects as well, in that environment the team is functionally managed by the project manager, rather than being self-managed.
Read more about the <span style=""color: #3366ff;""><a style=""color: #3366ff;"" href=""https://www.quickscrum.com/ScrumGuide/178/sg-Scrum-Development-Team"" target=""_blank"" rel=""noopener""><u>Scrum Development Team</u></a>’s</span> role.",,Scrum Roles,
3490,Sprint Planning,"Sprint planning meeting is a time-boxed working session that lasts roughly 1 hour for every week of a sprint. In sprint planning, the entire team agrees to complete a set of product backlog items within a Sprint. This agreement defines the sprint backlog and is based on the team’s velocity or capacity and the length of the sprint.
<h1>Meeting Specifics</h1>
<h3 style=""padding-left: 30px;"">Time-box:</h3>
<ul class=""custom-padding-left-30"">
<li>4 hours for 2 weeks sprint or 8 hours for 4 weeks sprint</li>
</ul>
<h3 style=""padding-left: 30px;"">Attendees:</h3>
<ul class=""custom-padding-left-30"">
<li><strong>Scrum Master:</strong> who facilitates the meeting.</li>
<li><strong>Product Owner:</strong> who clarifies the details of the product backlog items and their respective acceptance criteria.</li>
<li><strong>Development Team:</strong> who defines the work and effort necessary to meet the sprint commitment.</li>
</ul>
<h3 style=""padding-left: 30px;"">When:</h3>
<ul class=""custom-padding-left-30"">
<li>Before starting with a new sprint.</li>
</ul>
<h3 style=""padding-left: 30px;"">Inputs:</h3>
<ul class=""custom-padding-left-30"">
<li>Product Backlog</li>
<li>Team Capacity</li>
</ul>
<h3 style=""padding-left: 30px;"">Outputs:</h3>
<ul class=""custom-padding-left-30"">
<li><strong>Sprint Backlog:</strong> A sprint backlog is a list of the product backlog items the team commits to delivering plus the list of tasks necessary to delivering those product backlog items. Each task on the sprint backlog is also usually estimated.</li>
<li><strong>Sprint Goal:</strong> A sprint goal is a short, one- or two-sentence, description of what the team plans to achieve during the sprint. It is written collaboratively by the team and the product owner.</li>
</ul>
<h3 style=""padding-left: 30px;"">Sprint planning process:</h3>
<ul class=""custom-padding-left-30"">
<li>Establish goals for your sprint.</li>
<li>Choose the user stories that support those goals.</li>
<li>Break user stories into specific development tasks.</li>
<li>Create a sprint backlog.</li>
</ul>
<h3 style=""padding-left: 30px;"">Prior to Sprint Planning Meeting:</h3>
<p style=""padding-left: 30px;"">Prior to sprint planning, the Product Owner identifies the items with the greatest value and works towards getting them to a ready state. The development team tries to understand the functionality and technical aspects of user stories to be included in the sprint.</p>
<ul class=""custom-padding-left-30"">
<li>Assign a relative story point.</li>
<li>Remove dependencies.</li>
<li>Create testable examples.</li>
<li>Define acceptance criteria.</li>
<li>Meets INVEST criteria</li>
</ul>
<h1>Why sprint planning is important?</h1>
The idea behind the sprint planning is to provide understanding between development and the customer (or PO) when something new (and working) will be available, and to define the length of the feedback loop, which equals to the length of the sprint. In other words, the customer will know that He/she will get something in 2 weeks, which works, and the development team will know that they'll receive feedback on their work and know more about the upcoming work in two weeks. That's predictability.
<h1>Tips for effective sprint planning meetings</h1>
<ul class=""custom-padding-left-30"">
<li>Remind the team of the big picture or goal.</li>
<li>Discuss any new information that may impact the plan.</li>
<li>Present the velocity to be used for this release.</li>
<li>Confirm team capacity.</li>
<li>Review the definition of DONE and make any appropriate updates based on technology, skill, or team member changes since the last sprint.</li>
<li>Presently proposed product backlog items to consider for the sprint backlog.</li>
<li>Determine the needs, sign up for work, and estimate the work owned.</li>
<li>Product Owner answers clarifying questions and elaborates acceptance criteria.</li>
<li>Confirm any assumptions or dependencies discovered during planning and record.</li>
<li>Scrum Master calls for a group consensus on the plan.</li>
<li>Team and Product Owner agree upon the best plan they can make given what they know right now.</li>
<li><strong>Get back to work</strong></li>
</ul>
<ul class=""custom-padding-left-30"">
<li style=""list-style-type: none;""></li>
</ul>
",,Scrum Events,
3493,Sprint Retrospective,"The sprint retrospective is a meeting facilitated by the Scrum Master at which the team discusses the just-concluded sprint and determines what could change that might make the next sprint more productive. The sprint review looks at what the team is building, whereas the retrospective looks at how they are building it.
The sprint retrospective is an important mechanism that allows a team to continuously evolve and improve throughout the life of a project. It is important that everyone, including the team, product owner, and Scrum Master, get a chance to air their opinions in an open, honest, yet constructive atmosphere. It often also helps management to get feedback from the team about the work and progress of the project.
Retrospectives aren't used to record complaints - rather efforts are made by the team to find effective solutions to problems and develop action plans
<h2>Meeting Specifics</h2>
<h3 style=""padding-left: 30px;""><strong>Timebox :</strong></h3>
<ul class=""custom-padding-left-30"">
<li>2 hours (2 weeks sprint) / 4 hours (4 weeks sprint)</li>
</ul>
<h3 style=""padding-left: 30px;""><strong>Attendees :</strong></h3>
<ul class=""custom-padding-left-30"">
<li>Scrum Master</li>
<li>Product Owner</li>
<li>Scrum Team</li>
</ul>
<h3 style=""padding-left: 30px;"">When :</h3>
<ul class=""custom-padding-left-30"">
<li>At the end of the sprint</li>
</ul>
<h2>How is Sprint Retrospective held?</h2>
The Sprint Retrospective is held after the sprint review at the end of each sprint. During the retrospective, the team self-identifies elements of the process that did or did not work during the sprint, along with potential solutions. It aims to continuously improve the processes. Sprint Retrospective meetings can be facilitated by asking each person in the team to answer the following questions.
<ul>
<li>What went well during the sprint?</li>
<li>What would we like to change?</li>
<li>How can we implement that change?</li>
</ul>
Alternatively, instead of asking what went well and what didn’t go well, the following questions may be asked:
<ul>
<li>What should we start doing?</li>
<li>What should we stop doing?</li>
<li>What should we continue to do?</li>
</ul>
Additional topics can also be considered for discussion:
<ul>
<li><strong>Results: </strong>Compare the amount of work planned with what the development team actually completed. Review the sprint burndown chart and what it tells the development team about how they’re working.</li>
<li><strong>People: </strong>Discuss team composition and alignment.</li>
<li><strong>Relationships: </strong>Talk about communication, collaboration, and working in pairs.</li>
<li><strong>Processes:</strong> Go over getting support, development, and code review processes.</li>
<li><strong>Tools: </strong>How are the different tools working for the scrum team? Think about the artifacts, electronic tools, communication tools, and technical tools.</li>
<li><strong>Productivity: </strong>How can the team improve productivity and get the most work done within the next sprint?</li>
</ul>
Teams are asked to be specific in their answers so that effective actions can be taken. The retrospective meeting is usually conducted immediately after the Sprint review meeting. It is recommended that the entire team participate in this exercise so that any issues or concerns that the teams face during the previous Sprint are addressed during the teaming and avoided in upcoming Sprints.
<h2>Benefits of Retrospective:</h2>
Process improvements are made at the end of every sprint. This ensures that the project team is always improving the way it works.
<ul>
<li>The retrospective is a collaborative process among all members, including the team, the product owner, and the Scrum Master.</li>
<li>All team members identify what went well and what could be improved.</li>
<li>The team members discuss the process that they are following and give any suggestions for improvement.</li>
<li>The team members discuss any other ideas that could improve their productivity.</li>
<li>The Scrum Master prioritizes actions and lessons learned based on team direction.</li>
<li>The retrospective supports team formation and bonding, particularly as any areas of conflict can be identified and dealt with.</li>
<li>The retrospective helps build the team's sense of ownership and its self-management.</li>
</ul>
<h2>Tips for effective Retrospective:</h2>
<ul>
<li>Review notes and actions from the previous retrospective.</li>
<li>Ask what problems, successes and opportunities you have with the team, the product, and the process.</li>
<li>Let each team member speak without discussion.</li>
<li>Vote on the most important items to take action on.</li>
<li>Use “five whys” to discover the root cause of problems.</li>
<li>Create an action plan for your top priority items.</li>
<li>Explicitly allocate time for improvement actions.</li>
<li>Record your retrospectives & actions.</li>
</ul>",,Scrum Events,
3495,Estimate Story,"Agile emphasis to estimate a story in <strong>Story Point</strong> instead of hours.
<h1>What is a Story Point?</h1>
Story points represent the relative sizing of the user story. It is a unit of estimation used by Agile teams to estimate User Stories.
When the product owner wants some features to be developed he/she desires to know how soon the team can complete the features and how many resources it will take to complete the work. From the developer’s perspective, it’s next to impossible to predict the exact time in which he/she can complete the work. The person can, however, give a rough estimate in terms of how much time it might take to complete the work. Note that instead of “will” the developer chose to use “might” because he/she is not absolutely “sure” about the time factor but “feels” it might take that much time. This is user story estimation in a nutshell.
You don’t give an exact number explaining how complex the story is and how long it’ll take to develop – you give a rough “estimate”.
We are good at comparing size, so estimating a story using Fibonacci series sequence (0, 1, 2, 3, 5, 8, 13, 20, 40, and 100) gives more clarity of its complexity and relative sizing in terms of development. It is helpful to have a set of stories nearby to make a comparison and recommendation to set priority.
Here are the examples of relative sizing and its estimation points to develop the following vehicles:
<img class=""size-full wp-image-3496 aligncenter"" src=""http://137.116.134.50/wp-content/uploads/2018/09/estimating-in-agile-and-scrum_20161006105254114.jpg"" alt="""" width=""1091"" height=""405"" />
<h1>Consider the following factors while estimating stories</h1>
<ul class=""custom-padding-left-30"">
<li><strong>Complexity: </strong>Consider the complexity of the story.</li>
<li><strong>Risk: </strong>Consider the team’s inexperience with developing this story.</li>
<li><strong>Implementation: </strong>Consider the implementation factors.</li>
<li><strong>Deployment: </strong>Consider the deployment requirements.</li>
<li><strong>Interdependencies: </strong>Consider other outside issues.</li>
</ul>
<h1>Who should be involved in story Point estimation?</h1>
All team members who are responsible for getting a story done should ideally be part of the estimation.
<h1>Advantages of using story points for estimating work</h1>
<ul class=""custom-padding-left-30"">
<li>Story points are a measure of relative size and complexity.</li>
<li>Story points are unitless, meaning as a scale, they are only valuable to compare against each other within the same team.</li>
<li>Estimating in story points allows/encourages everyone, including business people to participate in the estimation process (using Planning Poker).</li>
<li>Estimating in story points is fast and easy.</li>
<li>Story points initiate high-level discussions about everything that is involved in a project.</li>
<li>Earned points can be used to generate the teams' velocity which can be used to predict future work capacity.</li>
</ul>
<h1>Steps to estimate stories</h1>
For each story to be sized, do the following as a team (Product Owner, Scrum master & Team member).
<h3 style=""padding-left: 30px;"">1. Identify base stories</h3>
<p style=""padding-left: 30px;"">Identify one or multiple base or reference story against which you would do relative sizing of the backlog. This story is picked from current product backlog or a different story which we have done earlier. But what is important is the understanding of this story is the same among everyone on the team. The team should be confident of this base story.</p>
<h3 style=""padding-left: 30px;"">2. Talk through the detailed requirements</h3>
<p style=""padding-left: 30px;"">Product Owner will answer questions and provide the explanation about what exactly this story entails.</p>
<h3 style=""padding-left: 30px;"">3. Discuss and note down points</h3>
<p style=""padding-left: 30px;"">These can be bullet points on the story card or text in the “notes” section of a tool. This is best done by Scrum Master who can add these details as and when discussions are on.</p>
<h3 style=""padding-left: 30px;"">4. Raise questions if any</h3>
<p style=""padding-left: 30px;"">During the discussion, the question may arise and must be clarified at the same time, Such as:</p>
<ul class=""custom-padding-left-30"">
<li><strong>Requirement: </strong>Any doubt about story requirement? Raise an alert. Ask product owner to give more clarity.</li>
<li><strong>Technical Feasibility: </strong>Can a story be delivered using current technology? Any unforeseen technical challenges must be surfaced.</li>
<li><strong>Acceptance Criteria: </strong>Team must clarify the checklist to be fulfilled to mark the story as accepted.</li>
<li><strong>Dependency: </strong>Does this story have external dependencies? If yes, that must be understood and resolved quickly.</li>
<li><strong>Expertise: </strong>Do we have enough skills to deliver the story? The team must have internal skills to deliver story otherwise delivery might be delayed or not done properly.</li>
</ul>
<h3 style=""padding-left: 30px;"">5. Agree upon estimated size</h3>
<p style=""padding-left: 30px;"">Every team members must agree upon estimated size decided on a story.</p>",,Monitor,
3499,Sprint Burn Down Chart,"<h1>What is a Sprint Burndown chart?</h1>
The Sprint Burndown Chart is a visual measurement tool that shows the completed work per day against the projected rate of completion for the current sprint. It provides transparency about the current performance (burndown rate) and allows easy estimation if the Sprint Goal can be reached in time or if the team has to find additional measures to speed-up completion of the remaining activities. The rate of progress of a Scrum Team is called ""velocity"". It expresses the amount of work in story points completed per sprint. An import rule for calculating the velocity is that only stories that are completed at the end of the sprint are counted. Counting partially finished work (e.g. coding only - test missing) is strictly forbidden.
<h1>Business value</h1>
It helps the user to understand how quickly your team has completed tasks, and predict when your team will achieve the goal or goals of the sprint.
<h1>What does a Burndown chart show?</h1>
<ul>
<li><strong>Total Estimate</strong></li>
</ul>
<p style=""padding-left: 30px;"">It is the sum of efforts in hours of all the user-stories, tickets, and issues, basically, it’s the total number of works in hours to which the team is committed to.</p>
<ul>
<li><strong>Amount of work Remaining or Effort Remaining</strong></li>
</ul>
<p style=""padding-left: 30px;"">This is what burn down shows and this is how this graph gets its name, in literal meaning, it is the “effort burndown chart”. The Team will burn down some effort each day so that on last day of sprint or release there is no work effort remains.</p>
<ul>
<li><strong>Working Days</strong></li>
</ul>
<p style=""padding-left: 30px;"">Since the team need to calculate and carefully work on the commit item each day, so that is the reason total days of commitment of work are shown in a graph. This is the total working days in a sprint (excluding holidays, weekend, etc.). This is actually your sprint duration.</p>
<ul>
<li><strong>Ideal Effort</strong></li>
</ul>
<p style=""padding-left: 30px;"">The ideal effort is drawn as a guide for a team, its drawn by calculating the exact amount of effort remaining which team need to burn down. That is the reason you see a very straight line from the top of the Y-axis to X-axis, which is the last day of your sprint.</p>
<ul>
<li><strong>Real Effort</strong></li>
</ul>
<p style=""padding-left: 30px;"">Effort remaining line varies from team to team and day to day. It depends on how much effort remaining is added or reduced each day. If more items (user stories and issues) are added after the sprint started, this show as an upward spike.</p>
<p style=""padding-left: 30px;""><strong>The chart can help in answering the following questions:</strong></p>
<ul class=""custom-padding-left-60"">
<li>How good is this team with the planning?</li>
<li>How well is this team executing against the planned stories in a Sprint?</li>
<li>Is this team self-organized and are they working in unison as a ""team""?</li>
<li>What improvements can this team make?</li>
</ul>
<h1>How to read Burndown chart :</h1>
The burndown chart is simple to understand :
<ul>
<li>X-axis for days of the sprint</li>
<li>Y-axis for effort (story points or hours or days depending on what you prefer)</li>
<li>An ideal line that visualizes expected progress</li>
<li>Real line visualizing the current progress</li>
</ul>
At the start of an iteration, the team estimates the work for all the tasks it commits to. The sum of all the hours estimated in story points for all the tasks is the starting point for the graph. Every day as the team members work on tasks, the remaining work plotted on the chart should also reduce. The chart should be updated each day and the graph should ideally display a downward trend. What makes the chart an effective reporting tool is that it shows the team's progress towards the Sprint Goal, not in terms of time spent but in terms of how much work remains.
<h1>Burndown chart samples</h1>
The following samples show the team status based upon the Burndown chart.
<h3 style=""padding-left: 30px;"">Type 1: Sprint commitment met</h3>
<p style=""padding-left: 30px;"">A burn-down chart in which sprint commitments are met and progress has been smooth over the sprint.</p>
<img class=""size-full wp-image-3501 alignnone"" src=""http://137.116.134.50/wp-content/uploads/2018/09/download.png"" alt="""" width=""1331"" height=""413"" />
<h3 style=""padding-left: 30px;"">Type 2: Sprint commitment not met</h3>
<p style=""padding-left: 30px;"">The teams are going at a slower pace and may not be able to complete all the commitments on time. The remaining work then becomes a part of the product backlog and is carried forward to subsequent sprints.</p>
<img class=""size-full wp-image-3504 aligncenter"" src=""http://137.116.134.50/wp-content/uploads/2018/09/download-1.png"" alt="""" width=""1331"" height=""413"" />
<h3 style=""padding-left: 30px;"">Type 3: Sprint commitment met early before time</h3>
<p style=""padding-left: 30px;"">It shows that we are going at a better rate and may be able to finish earlier. The stories were probably overestimated; therefore, the team finished them earlier.</p>
<img class=""size-full wp-image-3505 aligncenter"" src=""http://137.116.134.50/wp-content/uploads/2018/09/download-2.png"" alt="""" width=""1331"" height=""413"" />
<h1>Advantages of using Burndown charts</h1>
<ul>
<li>
<h3>Single planning and tracking tool for the team</h3>
</li>
</ul>
<p style=""padding-left: 30px;"">The team performs task breakdown, updates the estimated effort, and also updates the effort remaining. The entire team drives planning and tracking using the burn-down tool, which is the biggest advantage of using it.</p>
<ul>
<li>
<h3>Risk mitigation by daily visibility</h3>
</li>
</ul>
<p style=""padding-left: 30px;"">The burn-down chart provides daily feedback on effort and schedule, thereby mitigating risks and raising alarms as soon as something goes wrong, rather than waiting until the end.</p>
<ul>
<li>
<h3>Communication tool for customer and other stakeholders</h3>
</li>
</ul>
<p style=""padding-left: 30px;"">Burn-down charts provide visibility of a project’s progress on a daily basis. In the absence of an online tool, burn-down can be physically represented using a whiteboard/chart paper.</p>
<ul>
<li><strong>Placeholder to track retrospective action items</strong></li>
</ul>
<p style=""padding-left: 30px;"">It is a good practice to include retrospective action items from the previous sprint as ""functional requirements"" in the task breakdown for the current sprint. This way, the team keeps a focus on those action items and they are tracked as the sprint progresses.</p>
<h1>Common mistakes while using Burndown charts</h1>
<ul>
<li>If the task is too big, then it will make tracking on a daily basis difficult.</li>
<li>People get confused by the effort spent and the effort remaining. If these are wrongly plotted then the report insight will be inaccurate.</li>
<li>Forgetting to update the remaining time for tasks will lead to incorrect data.</li>
</ul>",,Monitor,
3507,User Stories,"A user story is a short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. There are different recommendations on how to define User stories. A template could be as follows :
As an [actor], I want [action] so that [business value / achievement]
<strong>Actor:</strong>
He/she is the 'owner' of the user story. This is often a user but it is recommended to be more specific here. By using specific actors (e.g. ""Administrator"", ""Logged in Customer"", ""Unauthenticated visitor"") it’s easier to understand and sets the user story into context.
<strong>Action:</strong>
Actual requirement of the actor in terms of feature.
<strong>Achievement:</strong>
Achievement specifies the Business value of action. This is the result of executing the action seen from the actor’s point of view. User stories are often written on index cards or sticky notes, stored in a shoe box, and arranged on walls or tables to facilitate planning and discussion. As such, they strongly shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written.
<h1>User story writing</h1>
User stories allow you to say why the features you’re proposing to build makes sense. A user story answers 3 important questions:
<p style=""padding-left: 30px;"">1. Who are you building this for?</p>
<p style=""padding-left: 30px;"">2. What are you building?</p>
<p style=""padding-left: 30px;"">3. Why are you building this?</p>
Example 1: As a user, I want to filter items by item type so that I can see how my team’s time is being used between features and bugs on a weekly basis.
Example 2: As a user, I want to filter items by item type so that I can create a report on everything we did this month for my boss.
Notice how changing one component of a user story would change your approach entirely? In the first case, you would probably display this information in a chart or graph for a simple breakdown of your team’s time. In the second example, you would likely create a function to export the data so it can be shared and presented.
With user stories, everyone in your team knows exactly “who,” “what,” and “why” they are building features. Each component adds a necessary layer of context to give your team a proper start. A user story immediately directs the focus to a specific circumstance which provokes further discussion and careful revision. The end result is that your team becomes more focused on delivering solutions to user problems as opposed to merely delivering functional code.
<h1>Why should I.N.V.E.S.T. be used to write good stories?</h1>
The <strong>I.N.V.E.S.T.</strong> guideline to writing user stories is almost universally accepted as the standard to work by. The acronym was made popular by Bill Wake’s original article from 2003. Our interpretation:
<h4>Independent</h4>
You should be able to prioritize and rearrange user stories in any way with no overlap or confusion.
<h4>Negotiable</h4>
As previously discussed, a good user story can be reworked or modified to best suit the business. User stories are not an explicit set of tasks.
<h4>Valuable</h4>
User stories need to be valuable. By this, we mean value for the business or the customer. If it’s not, why would you have your team work on it?
<h4>Estimable</h4>
A good user story can be estimated. It’s also important to differentiate time estimations from an exact timeframe. A rough estimate is beneficial to allow teams to rank and schedule their priorities.
<h4>Small</h4>
We definitely recommend keeping your user stories small. While we don’t suggest an exact timeframe to stay in, writing user stories that focus on smaller tasks allows for greater focus. The larger a story is, the harder it is to estimate and easier it is to get caught up in sub items that should have probably been their own stories.
<h4>Testable</h4>
Before a user story is written, it is essential that criteria to test it is in place. Outlining the testability first ensures that the story actually accomplishes the goal you are trying to achieve. A story is not finished until it is tested. For maximum productivity and team alignment, make sure your team knows how their work will be tested.
<h1>Benefits of writing user stories</h1>
<ul class=""custom-padding-left-30"">
<li>Helps to express the business value.</li>
<li>Avoid introducing detail too early that would prevent design options and inappropriately lock developers into one solution.</li>
<li>Avoid the appearance of false completeness and clarity.</li>
<li>Get to small enough chunks that invite negotiation and movement in the backlog.</li>
<li>Stories are comprehensible.</li>
<li>Developers and customers understand them.</li>
<li>People are better able to remember events if they are organized into stories.</li>
<li>They support and encourage iterative development.</li>
<li>They can be easily started as epics and later disaggregated at the development time.</li>
<li>Stories support opportunistic development.</li>
<li>Stories support participatory design.</li>
<li>Stories put the focus on the user’s goals</li>
</ul>",,Scrum Artifacts,
3510,Filter Workitem,"Quickscrum provides powerful <strong>quick search</strong> and <strong>advanced search</strong> feature to find out workitems matched to specific search criteria.
<strong><span style=""font-size: 32px;"">Quick Search</span></strong>
Quick search displays all workitems having their <strong>name</strong> <strong>matched fully or partially</strong> to the <strong>search text</strong>.
<img class=""alignnone size-full wp-image-6033"" src=""http://localhost/qs-guide/wp-content/uploads/2018/09/planning-filter-workitem-1.png"" alt="""" width=""1366"" height=""358"" />
<h1>Advanced Search</h1>
To search over workitems by specifying the multiple search criteria,
<p style=""padding-left: 30px;"">1. Click on the <strong>Add Filter</strong> button. It displays all filters available within that view. You can add the filters such as <strong>Created by, Priority, Timebox, Tags </strong>et<em>c</em>.</p>
<p style=""text-align: center; padding-left: 30px;""><img class=""alignnone size-full wp-image-6035"" src=""http://localhost/qs-guide/wp-content/uploads/2018/09/planning-filter-workitem-3.png"" alt="""" width=""1366"" height=""371"" /></p>
<p style=""padding-left: 30px;"">2. To remove a filter, place the mouse cursor on a filter and click on the <strong>X </strong>symbol.</p>
<p style=""text-align: center; padding-left: 30px;""><img class=""alignnone size-full wp-image-6036"" src=""http://localhost/qs-guide/wp-content/uploads/2018/09/planning-filter-workitem-4.png"" alt="""" width=""1366"" height=""371"" /></p>
<p style=""padding-left: 30px;"">3. Select the <strong>filter values </strong>and click on the <strong>Apply Filter</strong> button. It will display all workitems matched to the selected search criteria.</p>
<p style=""text-align: center; padding-left: 30px;""><img class=""alignnone size-full wp-image-6037"" src=""http://localhost/qs-guide/wp-content/uploads/2018/09/planning-filter-workitem-5.png"" alt="""" width=""1366"" height=""371"" /></p>
<p style=""padding-left: 30px;"">4. To remove the selected filter values click on the <strong>Reset</strong> icon.</p>
<p style=""padding-left: 30px;""><img class=""alignnone size-full wp-image-6038"" src=""http://localhost/qs-guide/wp-content/uploads/2018/09/planning-filter-workitem-6.png"" alt="""" width=""1366"" height=""371"" /></p>",,Planning,
3513,Scrum Ceremonies,"Meetings or ""ceremonies"" are an important part of agile development. They help to broadcast information to all team member, Bring common goal and vision, Share team progress appropriately.
<h1>Every project has two elements.</h1>
<ul>
<li><strong>The content aspect: </strong>What you commit to achieving, such as writing software or implementing virtualization</li>
<li><strong>The process aspect: </strong>The activities you perform to keep the content work on a track, such as updating Gantt charts and writing status reports.</li>
</ul>
<h1>Ceremonies or events in Scrum :</h1>
<ul>
<li><span style=""color: #3366ff;""><a style=""color: #3366ff;"" href=""https://www.quickscrum.com/ScrumGuide/177/sg-Daily-Stand-Up"" target=""_blank"" rel=""noopener"">Daily Scrum Meeting.</a></span></li>
<li><span style=""color: #3366ff;""><a style=""color: #3366ff;"" href=""https://www.quickscrum.com/ScrumGuide/174/sg-Sprint-Planning"" target=""_blank"" rel=""noopener"">Sprint Planning Meeting.</a></span></li>
<li><span style=""color: #3366ff;""><a style=""color: #3366ff;"" href=""https://www.quickscrum.com/ScrumGuide/173/sg-Sprint-Review-Meeting"" target=""_blank"" rel=""noopener"">Sprint Review/Demonstration Meeting.</a></span></li>
<li><span style=""color: #3366ff;""><a style=""color: #3366ff;"" href=""https://www.quickscrum.com/ScrumGuide/182/sg-Sprint-Retrospective-Meeting"" target=""_blank"" rel=""noopener"">Sprint Retrospection Meeting.</a></span></li>
<li><span style=""color: #3366ff;""><a style=""color: #3366ff;"" href=""https://www.quickscrum.com/ScrumGuide/170/sg-Product-Backlog-Refinement"" target=""_blank"" rel=""noopener"">Product backlog refinement or grooming.</a></span></li>
<li><span style=""color: #3366ff;""><a style=""color: #3366ff;"" href=""https://www.quickscrum.com/ScrumGuide/185/sg-Release-Planning"" target=""_blank"" rel=""noopener"">Release planning.</a></span></li>
</ul>
",,Scrum Events,
3517,Release Planning,"A very high-level plan for multiple Sprints (e.g. three to twelve iteration) is created during the Release planning. It is a guideline that reflects expectations about which features will be implemented and when they are completed. It also serves as a base to monitor progress within the project. Releases can be intermediate deliveries done during the project or the final delivery at the end. The purpose of release planning is to define the contents of a release or a specific shippable product increment.
<h1>What are the core objectives of release planning?</h1>
<ul>
<li>Resolve discrepancies between the product roadmap with a team commitment on what they can deliver in a release.</li>
<li>Extend visibility past a single sprint, so executives can make an informed budget and schedule decisions.</li>
<li>Give Scrum teams a chance to understand the complete set of functionality in the product.</li>
</ul>
<h1>How to do release planning</h1>
Take your product or project objectives and break it/them down to major features. Find out the indispensable options (primary features) under each major feature that must be present for delivery. Then include the additional features that would be nice to have (secondary features).
Now take this mix (product backlog) and, including the product owner and delivery team, lay these features against the fixed time blocks (for example, sprints or months or quarters) you're working with, and you have completed a draft release plan. Review the releases and features included and determine whether the resources are adequate and what interdependencies exist, and adjust the feature layout as needed. For this review, it would be ideal if you knew the team's velocity, in the case of an existing team — or had a reasonably assumed velocity if the team is new. Don't worry yet about the applied velocity; after observing a few sprints, you should be able to arrive at the actual average velocity and work this into the action plan. You may need to adjust resources and/or scope to realign to the plan.
To create a Release Plan the following things have to be available :
<ul>
<li>A prioritized and estimated Scrum Product Backlog.</li>
<li>The (estimated) velocity of the Scrum Team</li>
<li>Conditions of satisfaction (goals for the schedule, scope, resources).</li>
</ul>
If the project is feature-driven, the sum of all features within in a release can be divided by the expected velocity. This will then result in the number of sprints needed to complete the requested functionality. These release plans assume that there's an integrated development, testing, and deployment team. If you have separate Agile teams for these functions, consider creating separate release plans for each team.
Release planning should be carried out in a very systematic way :
<ul>
<li>Sketch a preliminary roadmap.</li>
<li>Add a degree of confidence.</li>
<li>Include dates and adjust as needed.</li>
<li>Update the plan every sprint.</li>
</ul>
Testers are also involved in release planning and perform the following activities :
<ul>
<li>Decide the team members responsible for testing.</li>
<li>Write user stories and acceptance criteria.</li>
<li>Work out the test environment that needs to be set up.</li>
<li>Create the test data to be used for testing purposes.</li>
<li>Specify the scope of testing and testing goals to be carried out.</li>
<li>Seek clarification on those user stories where there is insufficient information.</li>
<li>Determine the high-level test strategy for the whole release.</li>
<li>Point out any testing risks they might occur.</li>
<li>Do a high-level test planning.</li>
<li>Define the number of test levels to be performed.</li>
</ul>
Don’t attempt a release plan until the team and the product owner have estimated, ordered, and prioritized the initial product backlog.
<h1>Benefits of Release planning</h1>
<ul>
<li><strong>Accelerated Time to Value:</strong> By delivering services to customers on ever-shorter release cycles. The release management, test environment management and deployment processes are streamlined enabling changes to be deployed more rapidly. End users realize the benefits of changes a quickly as possible.</li>
<li><strong>Higher Release Throughput:</strong> By absorbing higher rates of change to systems whilst maintaining IT service quality through a unified, well-understood and controlled release process.</li>
<li><strong>Enhanced Agility and flexibility:</strong> By responding to new and emerging needs and competitive threats as they arise. With all parties operating on the basis of consistent information, whereby they can quickly understand the impact of new changes to the release schedule and risk profile of the release in order to respond positively to those demands.</li>
<li><strong>Increased Productivity:</strong> Through creation and enforcement of standards and best practices across the releases process as well as a more efficient allocation of test environments to support releases. Deliver smoother transitions of releases from development activities (projects) to final destination environment.</li>
<li><strong>Increased Collaboration:</strong> By bringing together disparate teams and skillsets, involved in the release management process, through information sharing and instant communication. All release stakeholders have complete and timely insights into schedules, changes, priority and status. Release management metrics are clear across the organization.</li>
<li><strong>Mitigate Release Failure:</strong> Through strong policy and governance that enables stakeholders to take preventative action based on superior information. Providing real-time visibility into enterprise-wide release status enables stakeholders to pinpoint the root cause of potential release failures and mitigate them quickly.</li>
</ul>
<h1>A few tips to make release planning effective</h1>
<ul>
<li>Do as little planning as is necessary.</li>
<li>Start release planning when you realize you need it, even if it’s near the end of the release effort.</li>
<li>Plan using stickies on the walls. If you must transcribe them into an online tool, do that later, after the meeting.</li>
<li>Don’t forget that each scrum team only commits to results for the next sprint. Everything else is merely an attempt to understand what could or should happen.</li>
<li>Release planning is not about committing to a list of features to be released on a certain date.</li>
<li>Include vendors and other third parties who are relevant and involved in your release planning meeting.</li>
<li>Revisit the release plan after each sprint and update it.</li>
<li>Don’t give in to the urge to publish a release plan as a separate document.</li>
<li>There’s no prescribed time box for release planning because it will vary with the size of the team and the expected length of the release effort.</li>
</ul>",,Scrum Events,
3522,Definition Of Done,"In order to be able to decide when an activity from the Sprint Backlog is completed, the Definition of Done (DoD) is used. In simple terms, Definition of Done is a simple list of activities (writing code, coding comments, unit testing, integration testing, release notes, design documents, etc.) that add verifiable/demonstrable value to the product. It includes a comprehensive checklist of necessary activities that ensure that only truly done features are delivered, not only in terms of functionality but in terms of quality as well. Focusing on value-added steps allows the team to focus on what must be completed in order to build software while eliminating wasteful activities that only complicate software development efforts. The DoD may vary from one Scrum Team to another but must be consistent within one team.
There might be different DoD at various levels:
1. DoD for a user story (e.g. writing code, tests and all necessary documentation)
2. DoD for a sprint (e.g. install demo system for review)
3. DoD for a release (e.g. writing release notes)
There are various factors which influence whether a given activity belongs in the DoD for a feature, a sprint or a release. Ultimately, the decision rests on the answer to the following three questions :
1. Can we do this activity for each feature/story? If not, then
2. Can we do this activity for each sprint? If not, then
3. We have to do this activity for our release
<h1>Story Definition of Done</h1>
What must happen for the story to be marked as complete:
<ul>
<li>All story should have an automated acceptance test.</li>
<li>The story should have working code supported by a unit test that provides around 60 – 70 per cent coverage.</li>
<li>The story should have well-defined acceptance criteria.</li>
<li>The code must have been written as a pair or should be code reviewed.</li>
<li>Code must be completely checked in to the source control system and the build should pass with all the automated tests running.</li>
<li>The product owner must accept the story.</li>
</ul>
<h1>Sprint Definition of Done</h1>
<ul>
<li>The product owner should have defined a sprint goal.</li>
<li>All stories completed for the spring must be accepted by the product owner.</li>
<li>All the automated acceptance tests should be running for the stories in the sprint.</li>
<li>All code should have been pair programmed or must have gone through a code review process.</li>
<li>If there is a database involved, the database scripts must have been automated and tested.</li>
</ul>
<h1>Release Definition of Done</h1>
<ul>
<li>The product is deployed to the test-box and makes it to the staging.</li>
<li>There are deployment documents for the release.</li>
<li>Training manuals are available for users.</li>
<li>All stories for the release are completed and accepted.</li>
<li>The release does not have any level one bugs.</li>
</ul>
<h1>The Evolving Definition of Done</h1>
A team’s Definition of Done won’t remain the same throughout the lifetime of the project and neither should it. As the team becomes more effective and productive and learns to work better, it will naturally enhance and refine its Definition of Done to produce more valuable and better quality features. It will start recognising patterns in the development processes and procedures required to produce high-quality features, and it'll start adding these to the DoD. It’s therefore important that the team gets regular opportunities to revisit the Definition of done and the natural place to do this is in the sprint retrospective meeting.
<h1>Definition of Done common impediments</h1>
Some of the common root causes of the impediments are:
<ul>
<li>The team does not have the skill set to incorporate activities into the definition of done for a sprint or for a feature.</li>
<li>The team does not have the right set of tools. (Example: continuous integration environment, automated build, servers etc.)</li>
<li>Team members are executing their sprint in mini-waterfalls. Aha! Opportunity to be more cross-functional. Sharing of responsibilities across functional silos.</li>
</ul>",,Monitor,
Sindbad File Manager Version 1.0, Coded By Sindbad EG ~ The Terrorists