Agile Methodology in Brief

Agile is a software development methodology to build software incrementally using short iterations of 1 to 4 weeks so that the development is aligned with the changing business needs.

Instead of a single-pass development of 6 to 18 months where all the requirements and risks are predicted upfront, Agile adopts a process of frequent feedback where a workable product is delivered after 1 to 4 week iteration.





The agile software development emphasizes on four 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




Scrum Process:




Scrum Events

The Sprint

A sprint is a time-boxed period during which specific work is completed and made ready for review. Sprints are usually 2-4 weeks long but can be as short as one week.

Sprint Planning

Sprint Planning team meetings are time-boxed events that determine which product backlog items will be delivered and how the work will be achieved.

The Daily Stand-up

The Daily Stand-up is a short communication meeting (no more than 15 minutes) in which each team member quickly and transparently covers progress since the last stand-up, planned work before the next meeting, and any impediments that may be blocking his or her progress.

The Sprint Review

The Sprint Review is the “show-and-tell” or demonstration event for the team to present the work completed during the sprint. The Product Owner checks the work against pre-defined acceptance criteria and either accepts or rejects the work. The stakeholders or clients give feedback to ensure that the delivered increment met the business need.

The Retrospective

The Retrospective, or Retro, is the final team meeting in the Sprint to determine what went well, what didn’t go well, and how the team can improve in the next Sprint. Attended by the team and the Scrum Master, the Retrospective is an important opportunity for the team to focus on its overall performance and identify strategies for continuous improvement on its processes


Scrum Artifacts

Product Backlog

The product backlog is the single most important document that outlines every requirement for a system, project or product. The product backlog can be thought of as a to-do list consisting of work items, each of which produces a deliverable with business value. Backlog items are ordered in terms of business value by the Product Owner.

Sprint Backlog

A sprint backlog is the specific list of items taken from the product backlog which are to be completed in a sprint.

Increment

An Increment is the sum of all product backlog items that have been completed since the last software release. While it is up to the Product Owner to decide on when an increment is released, it is the team’s responsibility to make sure everything that is included in an increment is ready to be released. This is also referred to as the Potentially Shippable Increment (PSI).

Scrum Rules

The rules of agile Scrum should be completely up to the team and governed by what works best for their processes. The best agile coaches will tell teams to start with the basic scrum events listed above and then inspect and adapt based on your team’s unique needs so there is continuous improvement in the way teams work together.



How the Process is done? An Example!

Having read about the technical jargons of SCRUM. let me try to demonstrate the whole process with an example.

Example:

Step #1: Let’s have a SCRUM team of 9 people comprising of 1 product owner, 1 Scrum master, 2 testers, 4 developers and 1 DBA.

Step #2: The Sprint is decided to follow a 4 weeks cycle. So we have 1-month Sprint starting 5th June to 4th of July.

Step #3: The Product owner has the prioritized list of user stories in the product backlog.

Step #4: The team decides to meet on 4th June for the “Pre Planning” meeting.

The product owner takes 1 story from the product backlog, describes it and leaves it to the team to brainstorm on it.
The entire team discusses and communicates directly to the product owner to have clearly understood the user story.


In a similar way, various other user stories are taken. If possible, the team can go ahead and size the stories as well.

After all the discussion, Individual team members go back to their workstations and Identify their individual tasks for each story.
Calculate the exact number of hours on which they will be working. Let’s check how the member concludes these hours.

Total number of working hours = 9
Minus 1 hour for a break, minus 1 hour for meetings, minus 1 hour for emails, discussions, troubleshooting etc.
So the actual working hours = 6.
A total number of working days during the Sprint = 21 days.
Total number of hours available = 21*6 = 126.
The member is on leave for 2 days = 12 hours (This varies for each member, some may take leave and some may not.)
Number of actual hours = 126 – 12 = 114 hours.

This means that the member will actually be available for 114 hours for this sprint. So he will break down his individual sprint task in such a way that a total of 114 hours is reached.

Step #5: On the 5th of June the entire Scrum team meets for the “Planning Meeting”.
The final verdict of the user story from the product backlog is done and the story is moved to the Sprint Backlog.
For each story, each team member declares their identified tasks, if required they can have a discussion on those tasks, can size or resize it (remember the Fibonacci series!!).
The Scrum master or the team enter their individual tasks along with their hours for each story in a tool.
After all the stories are completed, Scrum master notes the initial Velocity and formally starts the Sprint.

Step #6: Once the Sprint has started, based on the tasks assigned, each team member starts working on those tasks.

Step #7: The team meets daily for 15 minutes and discusses 3 things:
What did they do yesterday?
What they plan to do today?
Any impediments (roadblocks)?

Step #8: The scrum master tracks the progress on a daily basis with the help of “Burn down chart”.

Step #9: In case of any impediments, the Scrum master follows up to resolve those.

Step #10: On 4th July, the team meets again for the review meeting. A member demonstrates the implemented user story to the product owner.

Step #11: On 5th July, the Team meets again for the Retrospective, where they discuss:
What went well?
What did not go well?
Action Items.

Step #12: On 6th July, the Team again meets for pre-planning meeting for the next sprint and the cycle continues.




Scrum Activity Tools

There are several tools that can be used extensively for tracking the scrum activities.

Some of them include:
Jira
XPlanner




I hope the above explanation helps you people.


All the Best for your career.