Agile Scrum for absolute beginners in 5 mins

SCRUM FRAMEWORK - Roles, Activities, and Artifacts

Agile

Static, cumbersome software is no longer an option for competitive companies; it’s critical to develop processes that quickly iterate new code and release new features while simultaneously ensuring high quality. As a result, many companies have turned to Agile development methodology, which focuses on fast iterations and constant evaluation to produce flexible, robust and stable software. But understanding the value of Agile doesn’t guarantee easy adoption — adapting traditional QA processes to an Agile environment is not something you learn from a book, but a skill and culture developed through experience. Teams converting to agile have challenges not only in adapting processes and thinking differently, but also behaving differently. XBOSoft offers a unique blend of software testing expertise in development methodologies from waterfall to hybrid to Agile. Our depth of hands-on experience in a variety of industries gives us the ability to tailor and optimize an Agile testing process to each client’s specific needs.

Roles in Agile Scrum

1. Product Owner(converts & places the thoughts/clients requirements into Product backlog)
2. Scrum Master(drives the scrum teams to ensure smooth progress of the sprint)
3. Scrum team(BA, Developers & QA's responsible for developing & testing the sprint items)

Product Owner

· is the empowered central point of product leadership
· is the only authority responsible for what will be developed and in what order
· he maintains and communicates to all other participants a clear vision of what the Scrum team is trying to achieve
· as such, the product owner is responsible for the overall success of the solution being developed or maintained.

Scrum Master

· helps everyone involved understand and embrace the Scrum values, principles, and practices
· acts as a coach, providing development process leadership
· as a facilitator, ScrumMaster helps the team resolve issues and make improvements to its use of Scrum
· is responsible for protecting the team from outside interference
· takes a leadership role in removing impediments that inhibit team productivity
· has no authority to exert control over the team, so this role is not the same as the traditional role of project manager or development manager. The Scrum-Master functions as a leader, not a manager.

Development Team

· Traditional software development consists of various job types, such as architect, programmer, tester, database administrator, UI designer, etc. Scrum defines a development team as a diverse, cross-functional collection of people who are responsible for designing, building, and testing the desired product.
· the development team self-organizes to determine the best way to accomplish the goal set out by the product owner
· is typically five to nine people in size; its members must collectively have all skills needed to produce good quality, working software.

Scrum Activities and Artifacts

1. Product Backlog
2. Sprints
3. Sprint Planning
4. Sprint Execution
5. Daily Scrum
6. Sprint Review
7. Sprint Retrospective

Product Backlog

Using Scrum, we always do the most valuable work first. The product owner is responsible for determining and managing the sequence of this work and communicating it in the form of a prioritized (or ordered) list known as the product backlog. On new-product development the product backlog items initially are features required to meet the product owner’s vision. For ongoing product development, the product backlog might also contain new features, changes to existing features, defects, needing repair, technical improvements, etc.
The product owner collaborates with internal and external stakeholders to gather and define the product backlog items. He then ensures that product backlog items Scrum Activities and Artifacts are placed in the correct sequence. Items can be added, deleted, and revised by the product owner as business conditions change.
Overall the activity of creating and refining product backlog items, estimating them, and prioritizing them is known as grooming.
Size equates to cost, and product owners need to know an item’s cost to properly determine its priority. In practice, many teams use a relative size measure such as story points or ideal days.

Sprints

In Scrum, work is performed in iterations or cycles of up to a calendar month called sprints. The work completed in each sprint should create something of tangible value to the customer or user.
Sprints are time boxed so they always have a fixed start and end date, and generally they should all be of the same duration.

Sprint Planning

A product backlog may represent many weeks or months of work, which is much more than can be completed in a single, short sprint. To determine the most important subset of product backlog items to build in the next sprint, the product owner, development team, and ScrumMaster perform sprint planning.
During sprint planning, the product owner and development team agree on a sprint goal that defines what the upcoming sprint is supposed to achieve. Using this goal, the development team reviews the product backlog and determines the high priority items that the team can realistically accomplish in the upcoming sprint while working at a sustainable pace.
To acquire confidence in what it can get done, many development teams break down each targeted feature into a set of tasks. The collection of these tasks, along with their associated product backlog items, forms a second backlog called the sprint backlog.
The development team then provides an estimate (typically in hours) of the effort required to complete each task.

Sprint Execution

Once the Scrum team finishes sprint planning and agrees on the content of the next sprint, the development team, guided by the ScrumMaster’s coaching, performs all of the task-level work necessary to get the features done. “Done” means there is a high degree of confidence that all of the work necessary for producing good-quality features has been completed.
Team members define their own task-level work and then self-organize in any manner they feel is best for achieving the sprint goal.

Daily Scrum

Each day of the sprint, ideally at the same time, the development team members hold a timeboxed (15 minutes or less) daily scrum. This inspect-and adapt activity is sometimes referred to as the daily stand-up because of the common practice of everyone standing up during the meeting to help promote brevity.
A common approach to performing the daily scrum has the ScrumMaster facilitating and each team member taking turns answering three questions for the benefit of the other team members:
What did I accomplish since the last daily scrum?
What do I plan to work on by the next daily scrum?
What are the obstacles or impediments that are preventing me from making progress?
By answering these questions, everyone understands the big picture of what is occurring. The daily scrum is essential for helping the development team manage the fast, flexible flow of work within a sprint.
The daily scrum is not a problem-solving activity. Rather, many teams decide to talk about problems after the daily scrum and do so with a small group of interested people.
Done
In Scrum, we refer to the sprint results as a potentially shippable product increment, meaning that whatever the Scrum team agreed to do is really done according to its agreed-upon definition of done.

Sprint Review

At the end of the sprint there are two additional inspect-and-adapt activities. One is called the sprint review. The goal of this activity is to inspect and adapt the product that is being built. Critical to this activity is the conversation that takes place among its participants, which include the Scrum team, stakeholders, sponsors, customers, and interested members of other teams. The conversation is focused on reviewing the just-completed features in the context of the overall development effort.
A successful review results in bidirectional information flow. The people who aren’t on the Scrum team get to sync up on the development effort and help guide its direction. At the same time, the Scrum team members gain a deeper appreciation for the business and marketing side of their product by getting frequent feedback on the convergence of the product toward delighted customers or users. The sprint review therefore represents a scheduled opportunity to inspect and adapt the product.

Sprint Retrospective

The second inspect-and-adapt activity at the end of the sprint is the sprint retrospective. Whereas the sprint review is a time to inspect and adapt the product, the sprint retrospective is an opportunity to inspect and adapt the process. During the sprint retrospective the development team, ScrumMaster, and product owner come together to discuss what is and is not working with Scrum and associated technical practices.
At the end of a sprint retrospective the Scrum team should have identified and committed to a practical number of process improvement actions that will be undertaken by the Scrum team in the next sprint.
After the sprint retrospective is completed, the whole cycle is repeated again - starting with the next sprint-planning session, held to determine the current highest value set of work for the team to focus on.

The Scrum Artifacts are:

1. Product Backlog
2. Sprint Backlog
3. Incremental product

The Scrum Events are:

1. Sprint Planning
2. Daily Scrum
3. Sprint Review
4. Sprint Retrospective

Scrum Process

1. As an Initial Step, product owner interacts with clients & gathers the requirements
2. Writes up the requirements in Product backlog
3. Arranges them according to the priority & assigns them Stack Rank
4. Calculates the teams capacity based on No of sprint work days* total individuals per day capacity
5. Sprint planning is done based on the teams capacity, where the no of items are chosen based on the capacity of team.
6. Sprint Grooming is done during this phase to have an understanding on the PBI's (Product Backlog Items) being taken for the Sprint. Sprint grooming meeting is conducted to understand & clarify on the User Story to be delivered.
7. Work Items from product backlog are placed to sprint backlog based on Team's capacity
8. Now work Items are in Sprint backlog are are given story points which is a measure of efforts required to finish the task
9. Then QA/BA will write the Acceptance criteria & once reviewed & accepted by PO, Test Cases preparation & Identification to be taken over. In parallel development team starts with coding.

Acceptance Criteria

Before work begins on a PBI or bug, describe the criteria for customer acceptance as clearly as possible. Conversations between the team and customers to determine the acceptance criteria helps ensure a common understanding within the team to meet customers' expectations. The acceptance criteria can be used as the basis for acceptance tests so that the team can more effectively evaluate whether an item has been satisfactorily completed.

10. Daily stand up/Scrum meeting is conducted for 15 mins duration to identify any blockages & analyze the progress of WIT's
11. Once Build is delivered & accepted by QA, QA proceeds with testing the User Story, raises bugs & track to their closure
12. Demo the tested features to Product owner & the Client services team/stake holders.
13. Once the build is stabilized, its moved to staging[Pre-production] environments & High level sanity is performed
14. Then the build is deployed to the Production environment & then Post production testing is conducted to ensure the bug fixes work properly & User story tested works as expected.
15. Once done Bugs are closed from resolved state in Pre-production
16. User stories in resolved state will then be assigned to PO, where he the final check & closes the User story.
17. Once successful sprint release is done, Sprint retrospective meeting is conducted to analyze & bring out conclusions from last sprints experience.