Agile Methodology - Scrum

Agile Methodology:

Agile methodology is a practice that promotes continuous iteration of development and testing throughout the software development life cycle of the project. Both development and testing activities are concurrent unlike the Waterfall model.

The agile core values.

1.  Individual and team interactions over processes and tools
2.  Working software over comprehensive documentation
3.  Customer collaboration over contract negotiation
4.  Responding to change over following a plan

Different frameworks in Agile Methodology:

1. Scrum
2. Extreme Programming
3. Crystal Methodologies
4. Dynamic Software Development Method
5. Feature driven development
6. Lean Software Development

Above all are Agile frameworks. We will concentrate more on Scrum Framework.

Scrum Framework:  Scrum is an agile process framework for managing complex knowledge work, with an initial emphasis on software development, although it has been used in other fields and is slowly starting to be explored for other complex work, research and advanced technologies.

 It is designed for teams of ten or fewer members, who break their work into goals that can be completed within time-boxed iterations.

 Scrum contains multiple sprints. lets understand the sprints..

Sprints:

A sprint is a short, time-boxed period when a scrum team works to complete a set amount of work. Sprints are at the very heart of scrum and agile methodologies and getting sprints right will help your agile team ship better software with fewer headaches. 

Accordingly, teams usually define a short duration of a Sprint up to 2-4 weeks. Team collaboratively sets their target with Product Owner as "Sprint Goal" and plan their work in “Sprint backlog”. As soon race  starts after planning session, team work together to complete planned work effectively and make it ready for review by the end of that period.

Roles in Scrum:

1.  Product Owner
2.  Scrum master
3.  Scrum Team

     1. Product Owner: The product owner, representing the product's stakeholders and the voice of the customer (or may represent the desires of a committee, is responsible for delivering good business results.  Hence, the product owner is accountable for the product backlog and for maximizing the value that the team delivers. The product owner defines the product in customer centric terms (typically user stories), adds them to the product backlog, and prioritizes them based on importance and dependencies.

 Product owner Responsibilities:

1. Define and announce releases.
2. Communicate delivery and team status.
3. Share progress during governance meetings.
4. Share significant RIDAs (risks, impediments, dependencies, and assumptions) with stakeholders.
5. Negotiate priorities, scope, funding, and schedule.
6. Ensure that the product backlog is visible, transparent and clear.

2. Scrum master: Scrum is facilitated by a scrum master, who is accountable for removing impediments to the ability of the team to deliver the product goals and deliverables. The scrum master is not a traditional team lead or project manager but acts as a buffer between the team and any distracting influences. The scrum master ensures that the scrum framework is followed. The scrum master helps to ensure the team follows the agreed processes in the Scrum framework, often facilitates key sessions, and encourages the team to improve. The role has also been referred to as a team facilitator or servant-leader to reinforce these dual perspectives.

Responsibilities:

1. Helping the product owner maintain the product backlog in a way that ensures the needed work is well understood so the team can continually make forward progress
2. Helping the team to determine the definition of done for the product, with input from key stakeholders
3. Coaching the team, within the Scrum principles, in order to deliver high-quality features for its product
4. Promoting self-organization within the team
5. Helping the scrum team to avoid or remove impediments to its progress, whether internal or external to the team
6. Facilitating team events to ensure regular progress
7. Educating key stakeholders on Agile and Scrum principles
8. Coaching the development team in self-organization and cross-functionality

3. Scrum Team: The Scrum team has from three to nine members who carry out all tasks required to build increments of valuable output every sprint.

     While team members are referred to as developers in some literature, the term refers to anyone who plays a role in the development and support of the system or product, and can include researchers, architects, designers, data specialists, statisticians, analysts, engineers, programmers, and testers, among others. However, due to the confusion that can arise when some people do not feel the term 'developer' applies to them, they are often referred to just as team members.

   The team is self-organizing. While no work should come to the team except through the product owner, and the scrum master is expected to protect the team from too much distraction, the team should still be encouraged to interact directly with customers and/or stakeholders to gain maximum understanding and immediacy of feedback.

Scrum Ceremonies: Meetings, or "ceremonies" are an important part of agile development.  following are the Scrum ceremonies:

1.  Sprint Planning
2.  Daily Stand-up
3.  Sprint Review meeting
4.  Sprint Retrospective

1. Sprint Planning:

  Attendees: development team, scrum master, product owner

  When: At the beginning of a sprint.

  Duration: Usually an hour per week of iteration–e.g. a two-week sprint kicks off with a two-hour planning meeting.

  Purpose: Sprint planning sets up the entire team for success throughout the sprint. Coming into the meeting, the product owner will have a prioritized product backlog. They discuss each item with the development team, and the group collectively estimates the effort involved. The development team will then make a sprint forecast outlining how much work the team can complete from the product backlog. That body of work then becomes the sprint backlog.

2. Daily Stand-up

  Attendees: development team, scrum master, product owner

  When: Once per day, typically in the morning.

  Duration: No more than 15 minutes. Don't book a conference room and conduct the stand up sitting down. Standing up helps keep the meeting short!

  Purpose: Stand-up is designed to quickly inform everyone of what's going on across the team. It's not a detailed status meeting. The tone should be light and fun, but informative. Have each team member answer the following questions:

       What did I complete yesterday?

       What will I work on today?

       Am I blocked by anything?

3. Sprint Review Meeting:

  Attendees: 

         Required: development team, scrum master, product owner

         Optional: project stakeholders

  When: At the end of a sprint or milestone.

  Duration: 30-60 minutes.

   Purpose: Iteration review is a time to showcase the work of the team. They can be in a casual format like "demo Fridays", or in a more formal meeting structure. This is the time for the team to celebrate their accomplishments, demonstrate work finished within the iteration, and get immediate feedback from project stakeholders. Remember, work should be fully demonstrable and meet the team's quality bar to be considered complete and ready to showcase in the review.

4.  Sprint Retrospective

Attendees: development team, scrum master, product owner

 When: At the end of an iteration.

 Duration: 60 minutes.

 Purpose: Agile is about getting rapid feedback to make the product and development culture better. Retrospectives help the team understand what worked well–and what didn't.

Sprint Artifacts: Following are the sprint artifacts:

1.    Sprint Goal
2.    Product Backlog
3.    Sprint Backlog
4.    Definition of Done
5.    Sprint Burn-Down Chart

1. Sprint Goal : The Sprint Goal helps to focus the Sprint. It is the objective that will be met within the Sprint through the implementation of the forecasted Product Backlog items, and it provides guidance to the Development Team on why it is building the Product Increment.

 As per the Scrum Guide, the responsibility for crafting a Sprint Goal is for the Scrum Team. It is however in large part of interest to the Product Owner to support this process by having clear business goals for the coming Sprint, which can also make ordering the Product Backlog a lot easier by providing Focus.

2. Product Backlog: A product backlog is a list of all the things that are required in the product and it is a dynamic and best understood requirement for any changes to be made to the product. Product backlog owned by the Product Owner (PO) which consists of a list all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in the future releases.

Typically, the requirements of a product keep changing, i.e. change in business requirements, market conditions, or technology. Thus, product backlog is consistently updated to reflect what the product needs to be most useful to the target users.

3. Sprint Backlog: The Sprint Backlog is the set of Product Backlog items selected for the Sprint plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality. The Sprint Backlog defines the work the Development Team will perform to turn Product Backlog items into a “Done” Increment. The Sprint Backlog makes visible all of the work that the Development Team identifies as necessary to meet the Sprint Goal.

4. Definition of Done: Every Product Backlog item has acceptance criteria that define measurably what must be met when the item is declared to be done. Many criteria apply to all or many Product Backlog items. Instead of repeatedly defining these criteria with each item, it has proven to be useful to collect these criteria in one place: the Definition of Done.  Thus, the Definition of Done is a shared understanding of the Scrum Team on the meaning of work to be complete. It typically contains quality criteria, constraints and overall non-functional requirements. Here is some examples:

5. Sprint Burn-Down Chart:At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed. The Team tracks this total work remaining for every Daily Scrum to project the likelihood of achieving the Sprint Goal. By tracking the remaining work throughout the Sprint, the Team can manage its progress.

Sprint Burn-Down Chart is a practice for trending the work expended by the Scrum Team. This has been proven to be a useful technique in monitoring the Sprint progress towards the Sprint Goal.

The Product Owner tracks this total work remaining at least every Sprint Review. The Product Owner compares this amount with work remaining at previous Sprint Reviews to assess progress toward completing the projected work by the desired time for the goal. This information is shared with all stakeholders.