agile, Scrum
1. Scrum Overview
1.1 Iterative Incremental Model
In the iterative incremental model, the development starts with a limited number of finalized and prioritized requirements. The deliverable is a working increment of the product. A set of activities ranging from requirements to code development is called an iteration. Based on the functionality of the increment and any or all of the new, modified, pending requirements, the next lot of requirements is given to the subsequent iteration. The outcome of the subsequent iteration is an enhanced working increment of the product. This is repeated till the product accomplishes the required functionalities.
Agile development is based on iterative incremental development, in which requirements and solutions evolve through team collaboration. It recommends a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a theoretical framework and does not specify any particular practice that a development team should follow. Scrum is a specific agile process framework that defines the practices required to be followed.
2. Each Agile Development Scrum team having three core scrum roles: Product Owner, Scrum Master& The Team.
Product Owner: The Product Owner is the person who represents the stakeholders and is the voice of the customer. Product owner writes the User Stories, ordered priorities and add in the Product Backlog. It is recommended that Agile Scrum Master should not mix with Product Owner; both members should be different as each member having its own responsibilities.
Scrum Master: The ScrumMaster is a facilitative team leader who ensures that the team adheres to its chosen process and removes blocking issue to deliver the sprint deliverable/goal. Scrum Master is not a team leader but act as a shield for the team from external interference's & also removes barries. ScrumMaster facilitates the daily scrums.
The Team: The scrum development team is generally size of 5-9 peoples with self-organizing and cross-functional skills who do actual work like Analysis, Design, Development, Testing, Documentation etc.
3 Scrum Process Framework
3.1 Sprint Overview
The heart of Scrum is a Sprint, a time-box of two weeks or one month during which a potentially releasable product increment is created. A new Sprint starts immediately after the conclusion of the previous Sprint. Sprints consist of the Sprint planning, daily scrums, the development work, the Spring review, and the Sprint retrospective.
In Sprint planning, the work to be performed in the Sprint is planed collaboratively by the Scrum Team.
The Daily Scrum Meeting is a 15-minute time-boxed event for the Scrum Team to synchronize the activities and create a plan for that day.
A Sprint Review is held at the end of the Sprint to inspect the Increment and make changes to the Product Backlog, if needed.
The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. In this meeting, the Scrum Team is to inspect itself and create a plan for improvements to be enacted during the subsequent Sprint.
3.2 Sprint
A sprint (or iteration) is the basic unit of development in Scrum. The sprint is a timeboxed effort; that is, it is restricted to a specific duration. The duration is fixed in advance for each sprint and is normally between one week and one month, with two weeks being the most common.
Each sprint starts with a sprint planning event that aims to define a sprint backlog, identify the work for the sprint, and make an estimated forecast for sprint goal. Each sprint ends with a sprint review and sprint retrospective, that reviews progress to show to stakeholders and identify lessons and improvements for the next sprints.
Scrum emphasizes working product at the end of the sprint that is really done. In the case of software, this likely includes that the software has been fully integrated, tested and documented, and is potentially shippable.
3.3 Sprint planning
At the beginning of a sprint, the scrum team holds a sprint planning event to:
Mutually discuss and agree on the scope of work that is intended to be done during that sprint
Select product backlog items that can be completed in one sprint
Prepare a sprint backlog that includes the work needed to complete the selected product backlog items
The recommended duration is four hours for a two-week sprint(pro-rata for other sprint durations)
During the first half, the whole scrum team(development team, scrum master, and product owner) selects the product backlog items they believe could be completed in that sprint
During the second half, the development team identifies the detailed work(tasks) required to complete those product backlog items; resulting in a confirmed sprint backlog
As the detailed work is elaborated, some product backlog items may be split or put back into the product backlog if the team no longer believes they can completed the required work in a single sprint
Once the development team has prepared their sprint backlog, they forecast(usually by voting) which tasks will be delivered within the sprint.
3.4 Daily Scrum
Each day during a sprint, the team holds a daily scrum( or stand - up) with specific guidelines:
All members of the development team come prepared. The daily scrum:
starts precisely on time even if some development team members are missing
should happen at the same time and place every day
is limited(timeboxed) to fifteen minutes
Anyone is welcome, though only development team members should contribute
During the daily scrum, each team member typically answers three questions:
what did I complete yesterday that contributed to the team meeting our sprint goal?
What do I plan to complete today to contributed to the team meeting our sprint goal?
Do I see any impediment that could prevent me or the team from meeting our sprint goal?
Any impediment (e.g., stumbling block, risk, issue, delayed dependency, assumption proved unfounded)identified in the daily scrum should be captured by the scrum master and displayed on the team's scrum board or on a shared risk board, with an agreed person designated to working toward a resolution (outside of the daily scrum). No detailed discussions should happen during the daily scrum.
4. ScrumMaster
ScrumMaster is a trained responsible person, who renders services as described below:
4.1 ScrumMaster Services to the Product Owner
The ScrumMaster serves the Product Owner in several ways, including -
Finding techniques for effective Product Backlog management
Helping the Scrum Team understand the need for clear and concise Product Backlog items.
Understanding product planning in an empirical environment.
Ensuring that the Product Owner knows how to arrange the Product Backlog to maximize value.
Understanding and practicing agility.
Facilitating Scrum events as needed.
5 terms
5.1 Product backlog
The product backlog:
Captures requests to modify a product—including new features, replacing old features, removing features, and fixing issues
Ensures the development team has work that maximizes business benefit to the product owner
Typically, the product owner and the scrum team come together and write down everything that must be prioritized, and this becomes content for the first sprint—which is a block of time meant for focused work on selected items that can be accommodated within a timeframe. The product backlog can evolve as new information surfaces about the product and about its customers, and so later sprints may address new work.
The following items typically comprise a product backlog: features, bugs, technical work, and knowledge acquisition. A feature is wanted, while a bug is unintended or unwanted (but may not be necessarily something defective). An example of technical work could be to run a virus check on all developers' workstations. An example of knowledge acquisition could be to research Wordpress plugin libraries and making a selection.
5.2 Management
A product backlog, in its simplest form, is merely a list of items to work on. Having well-established rules about how work is added, removed and ordered helps the whole team make better decisions about how to change the product.[32]
The product owner prioritizes product backlog items based on which are needed soonest. The team then chooses which items they can complete in the coming sprint. On the scrum board, the team moves items from the product backlog to the sprint backlog, which is the list of items they will build. Conceptually, it is ideal for the team to only select what they think they can accomplish from the top of the list, but it is not unusual to see in practice that teams are able to take lower-priority items from the list along with the top ones selected. This normally happens because there is time left within the sprint to accommodate more work. Items at the top of the backlog, the items to work on first, should be broken down into stories that are suitable for the development team to work on. The further down the backlog goes, the less refined the items should be. As Schwaber and Beedle put it "The lower the priority, the less detail, until you can barely make out the backlog item."[1]
As the team works through the backlog, it must be assumed that change happens outside their environment—the team can learn about new market opportunities to take advantage of, competitor threats that arise, and feedback from customers that can change the way the product was meant to work. All of these new ideas tend to trigger the team to adapt the backlog to incorporate new knowledge. This is part of the fundamental mindset of an agile team. The world changes, the backlog is never finished.
5.3 Sprint backlog
The sprint backlog is the list of work the development team must address during the next sprint.[30]The list is derived by the scrum team progressively selecting product backlog items in priority order from the top of the product backlog until they feel they have enough work to fill the sprint. The development team should keep in mind its past performance assessing its capacity for the new sprint, and use this as a guide line of how much 'effort' they can complete.
The product backlog items may be broken down into tasks by the development team.[30]Tasks on the sprint backlog are never assigned; rather, tasks are signed up for by the team members as needed according to the set priority and the skills of the team. This promotes self-organization of the development team, and developer buy-in.
The sprint backlog is the property of the development team, and all included estimates are provided by the development team. Often an accompanying task board is used to see and change the state of the tasks of the current sprint, like to do, in progress and done.
Once a sprint backlog is committed, no additional work can be added to the sprint backlog except by the team. Once a sprint has been delivered, the product backlog is analyzed and reprioritized if necessary, and the next set of functionality is selected for the next sprint.
5.4 Product increment
The increment (or potentially shippable increment, PSI) is the sum of all the product backlog items completed during a sprint, integrated with the work of all previous sprints. At the end of a sprint, the increment must be complete, according to the scrum team's definition of done (DoD), fully functioning, and in a usable condition regardless of whether the product owner decides to actually release it.
Last updated
Was this helpful?