web analytics
Sign In | Register
Welcome, Guest
1 2 3 4

Overview of Scrum Methodology

 Options
Previous Topic Next Topic

codeling 1599 - 6654
@2019-02-21 09:29:29

Scrum project management is a methodology for managing software delivery that comes under the broader umbrella of agile project management. It provides a lightweight process framework that embraces iterative and incremental practices, helping organizations deliver working software more frequently. Projects progress via a series of iterations called sprints; at the end of each sprint the team produces a potentially deliverable product increment.

Activities in Scrum Project Management

The main activity in Scrum project management is the Sprint, a time boxed iteration that usually lasts between 1-4 weeks, with the most common sprint length being 2 weeks.

  • Sprint Planning Meeting: at the start of each sprint a planning meeting is held to discuss the work that is to be done. The product owner and the team meet to discuss the highest-priority items on the product backlog. Team members figure out how many items they can commit to and then create a sprint backlog, which is a list of the tasks to complete during the sprint.
  • Daily Scrum or Daily Standup: each day during the sprint team members share what they worked on the prior day, will work on today, and identify any impediments. Daily scrums serve to synchronize the work of team members as they discuss the work of the sprint. These meetings are time boxed to no more than 15 minutes.
  • Backlog Grooming: backlog grooming, also referred to as backlog refinement, was not originally a formal meeting in the Scrum framework. But from the practice perspective, backlog grooming is a necessary meeting to ensure the product backlog items (PBIs) are given given additional details and are prioritized for upcoming sprint planning. It is advised that the teams dedicate about 5 to 10 percent of every sprint time to this activity in the middle of a sprint. 
  • Sprint Review: at the end of a sprint the team demonstrates the functionality added during the sprint. The goal of this meeting is to get feedback from the product owner and any users or other stakeholders who have been invited to the review.
  • Sprint Retrospective: at the end of each sprint the team participates in a retrospective meeting to reflect on the sprint that is ending and identify opportunities to improve in the new sprint.

Artifacts in Scrum Project Management

Scrum Project Management requires very few artifacts, concentrating instead on delivering software that produces business value. The main artifacts in Scrum are:

  • Product Backlog: this is a complete list of the functionality that remains to be added to the product. The product backlog is prioritized by the product owner so that the team always works on the most valuable features first.
  • Sprint Backlog: this is a prioritized list of tasks the team needs to complete during the sprint.
  • Burndown charts: these are used to show the amount of work remaining in a sprint and provide an effective way to determine at a glance whether a sprint is on schedule to have all planned work finished.

Roles on a Scrum team

There are three main roles involved in Scrum project management:

  • The Product Owner serves as the customer proxy and is responsible for representing the interests of the stakeholders and ensuring that the product backlog remains prioritized.
  • The ScrumMaster is responsible for implementing the Scrum. A ScrumMaster differs from a traditional project manager in many key ways, including that the ScrumMaster does not provide day-to-day direction to the team and does not assign tasks to individuals. A key part of this role is to remove impediments or issues that might slow the team down or stop activity that moves the project forward.
  • The Team is made up of a cross-functional group of 5-9 members who are responsible for developing the product. Scrum teams are self-organized will all members collectively responsible for getting the work done.
@2019-02-22 09:44:35

In 2010, Scrum.org codified Scrum by creating and publishing the Scrum Guide for free. This roughly 15-page guide represents the official rules of Scrum and is maintained by Scrum’s creators, Ken Schwaber and Jeff Sutherland. It is available in 30 languages and downloadable at http://www.scrum.org/scrumguides.
@2019-02-22 09:56:49

In Scrum, the Product Backlog is the single source of requirements for any changes to be made to the software product. This list includes features to be added, as well as bugs to be fixed. It is the Product Owner’s responsibility to ensure that the Product Backlog is available, transparent, understood by the Development Team, and ordered (prioritized). The Development Team collaborates with the Product Owner, and others as needed, during Sprint Planning and Product Backlog grooming to understand and estimate the effort required to deliver the items in the Product Backlog.

The Sprint is a time-boxed event that contains the other Scrum events. Sprints should be a month or less in duration. The first event within a Sprint is the Sprint Planning meeting. In this time-boxed event, the Scrum team collaborates to plan the work of the upcoming Sprint. The Product Backlog items (PBIs), ordered at the top of the Product Backlog by the Product Owner, are discussed. The Development Team forecasts those Product Backlog items that it believes it can complete by the end of the Sprint. A Sprint Goal is crafted, and the Sprint Backlog emerges. The Sprint Backlog contains those items selected by the Development Team plus a plan for delivering them. The Sprint Backlog shows the work remaining in the Sprint at all times.

The bulk of the Sprint’s time-box will be spent developing the items in the Sprint Backlog. The rules of Scrum are fairly silent on what occurs each day during development. The Development Team must meet regularly for the Daily Scrum. This short meeting is for the Development Team to synchronize on what work will be executed in the next 24 hours. The Development Team should also meet with the Product Owner to groom the Product Backlog. During the Backlog Grooming, items in the Product Backlog are given additional detail, and estimates are given by the Development Team. This keeps the Product Backlog healthy so that the Product Owner can plan the software product’s release and make better decisions on the items to develop next.

During the Sprint, the Development Team completes items in their Sprint Backlog according to each item’s acceptance criteria and the team’s Definition of “Done”. This definition lists the practices and standards that must be met for every item before it can be considered complete.The definition is created by the Development Team but must be understood by the Product Owner. Both parties must understand that if work does not meet the Definition of “Done,” it is not done and cannot be released. Ideally, the Development Team collaborates with the Product Owner throughout the Sprint to ensure that all criteria are being met. If the Development Team completes their forecasted work early, they should collaborate with the Product Owner to find another suitable Product Backlog item to work on. Conversely, at the first indication that the Development Team knows that they won’t be able to complete their forecasted work, they should collaborate with the Product Owner to identify and discuss trade-offs and modify the Sprint Backlog to reflect the reality of the Sprint without sacrificing quality.

Sprint Backlog items done according the Development Team’s definition are demonstrated during the Sprint Review meeting. The Product Owner may invite various stakeholders to this meeting for their feedback on the Increment. This Product Owner and stakeholder feedback might be captured and end up as new items in the Product Backlog. Existing items may also need to be updated or removed. The Product Owner may decide to release the Increment as soon as possible or delay it. This should be a business decision. Regardless of when the Increment is released, the Development Team should always develop the Increment as though it were going to be released as soon as possible.

The last event in the Sprint is the Sprint Retrospective meeting. This meeting provides an opportunity for the Scrum Team to inspect themselves and identify what went well and what needs improving. If improvements are identified, the team should create an actionable plan for the next Sprint. Nothing is out of scope during this meeting—people, relationships, process, and tools can all be discussed. The Scrum Team may also decide to adjust its Definition of “Done” to increase product quality. After the meeting, the next Sprint begins.
@2019-03-01 10:30:40

The Scrum Team consists of the following Scrum roles:

  • Development Team
  • Product Owner
  • Scrum Master

The Product Owner represents the voice of the user. This means the Product Owner not only knows the product, its domain, and its vision, but also the users.

  • There is only one Product Owner on a Scrum Team.
  • The Product Owner is responsible for maximizing the value of the product through the work of the Development Team. The Product Owner’s primary communication tool for doing this is a well-groomed and -ordered Product Backlog.
  • The Product Owner should be considered the go-to person for all questions about the product’s vision, value, release goals, features, and bugs. When the developers have a question about the product, their first instinct should be to ask the Product Owner.
  • The Product owner has authority to make decisions related to the direction of the product, be highly available to the rest of the Scrum Team, and have good people skills.

The Development Team performs all of the work (burn their business cards) required to deliver the done increment of the software product. Also, there are no subteams in Scrum, such as testing or QA.

The Scrum Master enacts the Scrum values, practices, and rules throughout the Scrum Team and even the organization. He or she ensures that the Product Owner and Development Team are functional and productive by providing necessary guidance and support. The Scrum Master is not a technical role. Having a strong background in software development is not necessary, though it can be helpful at times. Scrum Masters must really know Scrum.

The Product Owner is the visionary leader who chooses what is built, when it is ready to release, and when to stop or cancel the project. If you think of the roles in terms of providing service, the Development Team serves the Product Owner, while the Scrum Master serves both the Development Team and the Product Owner. Therefore, the Development Team has strong influence to select (that is, hire or fire) the Scrum Master. Correspondingly, the Product Owner has strong influence to select the Development Team he or she wants to turn the Product Backlog into done Increments.
Previous Topic Next Topic
1 2 3 4

Comments
You must Sign In to comment on this topic.


© 2024 Digcode.com