What is Agile?
Agile software development methodology is more versatile to changes as there is no in-depth planning at the beginning of a project rather there are changing requirements throughout the process of the project. Constant feedback from the end users is encouraged. In agile, there is an incremental and iterative development approach. The work is prioritized based on business or customer value. Agile methodology is a practice that helps continuous iteration of development and testing in the SDLC process. Agile breaks the product into smaller builds. Each iteration focused on producing a working product.
Principles of the Agile Manifesto:
- Customer satisfaction is of highest priority, which achieved through the continuous delivery of valuable software.
- Accommodate changing requirements even in later phases of development.
- Deliver working software frequently in a shorter timescale.
- Business team and developers must collaborate on a daily basis throughout the project.
- Higher autonomy is given to the team members with greater support and trust.
- Face-to-face interaction is critical for conveying information within a development team.
- The progress of the project measured by working software.
- Promote sustainable development by maintaining a constant pace indefinitely.
- Technical excellence and good design should be the focus.
- Simplicity is essential for progress.
- Self-organizing teams are required for the best architectures and designs.
- The teams should reflect on how to become more productive regularly and adopt the changes to increase effectiveness.
Agile testing methodology
In this blog, we are focusing on ‘Agile methodology with scrum’.
Scrum is a subset of Agile. It is a transparent process framework for agile development, and the most widely used one. A “process framework” is a particular set of practice that must be followed in order for a process to be consistent with the framework.
Scrum is an agile framework that allows us to focus on delivering the business value in the shortest time. The Scrum Framework traditionally deals with the fact that the requirements are likely to change or most of the time not known at the beginning of the project.
- Product Owner
- Possibly a Product Manager or Project Sponsor
- Decides features, release date, prioritizes, $$$
- The Product Owner creates product backlog, prioritizes the backlog and is responsible for the delivery of the functionality at each iteration
- Scrum Master
- Typically a Project Manager or Team Leader
- Responsible for enacting Scrum values and practices
- Remove impediments/politics, keeps everyone productive
- Master is responsible for setting up the team, sprint meeting and removes obstacles to progress
- 5-10 members; Teams are self-organizing
- The team manages its own work and organizes the work to complete the sprint or cycle
- Cross-functional, QA, Programmers, UI Designers, etc.
- Sprint Planning
- Sprint planning meeting will be attended by the Product Owner, Scrum master and the entire Scrum Team. External stakeholders may attend by invitation of the team, although this is rare in most companies.
- During the sprint planning meeting, the product owner narrates the highest priority features to the team. The team asks sufficient questions by that they can turn a high-level user story of the product backlog into the more detailed tasks of the sprint backlog.
- Result from a sprint planning meeting
- Sprint goal: A sprint goal is a short, one- or two-sentence, description of what the team plans to achieve during the sprint. The team and the product owner write it collaboratively.
- Sprint backlog: The sprint backlog is the other output of sprint planning. A sprint backlog is a list of the product backlog items that the team commits to delivering plus the list of tasks needful to delivering those items from the product backlog. Each task on the sprint backlog are usually an estimate.
- Sprint Review
- Team illustrate what it accomplished during the sprint
- Typically takes the form of a demo of new features or underlying architecture
- Informal – 2-hour prep time rule
- No slides
- The whole team participates
- It is a Sprint Review Not a Sprint Demo!
- Although a demonstration is a helpful part of a sprint review, it is not the aim of the sprint review. The most important aspect of the sprint review is the in-depth conversation and collaboration among the participants that enable productive adaptations to surface and exploited.
- Sprint Retrospective
- Sprint retrospective is a time to reflect on the process, we need the full Scrum team to attend. This includes all members of the development team, the scrum master, and the product owner.
- The sprint retrospective is an opportunity to inspect and adapt the process. During the retrospective, teams are free to examine what is happening, analyze the way they work, identify ways to improve and make plans to implement these improvements.
- Anything that affects how the team develops the product is open to inspection and discussion, including processes, practices, communication, environment, coding standards, artifacts, tools, and so on.
- Daily Scrum Meeting
- Daily ~15 minutes stand-up meeting
- Not for problem-solving
- Team members, Scrum Master can talk
- Helps avoid other unnecessary meetings
- Three questions answered by each team member:
- What did you do yesterday?
- What will you do today?
- What obstacles are in your way?
- Product Backlog
- The requirements
- A list of all desired work on the project
- Ideally expressed as a list of user stories along with “story points”, such that each item has value to users or customers of the product
- Prioritized by the product owner
- Re-prioritized at the start of each sprint
- Sprint Backlog
- The team then compares the sprint backlog against its predicted available capacity (measured in effort hours) to determine if the amount of work it has chosen is realistic. Some teams prefer to measure capacity in terms of story points (historical velocity)
- Individuals sign up for work of their own choosing
- Work is never assigned
- Estimated work remaining would be updated on daily basis
- Team member can add, delete change sprint backlog
- Work for the sprint appear
- If work is uncertain then define a sprint backlog item with a larger amount of estimation time and break it down later
- Update work remaining as more known in the backlog
- Burn Down Chart
- A display of what work has been completed and what is left to complete
- One for each developer or work item
- Updated every day (Make the best guess about hours/points completed each day)
- variation: Release burndown chart
- Shows overall progress updated at end of each sprint
- User Stories
- User stories are short, simple elucidation of a feature told from the view of the person who wants the new potential, usually a user or customer of the system.
- They typically follow a simple template: As a < type of user >, I want < some goal > so that < some reason >.
- User stories are often written on index cards or sticky notes, stored in a box, and arranged on walls or tables to facilitate planning and discussion.
- As such, they explosively shift the focus from writing about features to discussing them. In fact, these discussions are more crucial than whatever text was written.
- Anyone can write user stories. It is the product owner’s responsibility to make sure a product backlog of agile user stories exists, but that does not mean that the product owner is the one who writes them.
- Detail can be added to user stories in two ways:
- By diverging a user story into multiple and smaller user stories.
- By adding, “Conditions of satisfaction.”