AGILE METHODOLOGIES in Software Technologies – Part – 1

Payilagam > Blog > Blogs > AGILE METHODOLOGIES in Software Technologies – Part – 1

AGILE METHODOLOGIES in Software Technologies – Part – 1 

This blog explains about AGILE METHODOLOGIES in Software Technologies – Part – 1 . It is illustrated very well below : 

_______________________________________________________________________________

AGILE  METHODOLOGIES

  • Agile is a software development approach where a self-sufficient and cross-functional team works on making continuous deliveries through iterations and evolves throughout the process by gathering feedback from the end users.
  • Agile requires a cultural shift in many companies because it focuses on the clean delivery of individual pieces or parts of the software and not on the entire application.
  • Agile software development allows the team to work together more efficiently and effectively in developing complex projects.

Why Agile:

   The conventional software models such as Waterfall Model that depends on completely specifying the requirements, designing, and testing the system are not geared towards rapid software development. As a consequence, a conventional software development model fails to deliver the required product. This is where the agile software development comes to the rescue. It was specially designed to curate the needs of the rapidly changing environment by embracing the idea of incremental development and develop the actual final product.

Scrum

        Scrum can easily be considered to be the most popular agile framework. A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

Scrum is:

  • Lightweight
  • Simple to understand
  • Difficult to master

 The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules.

  Important SCRUM Terminologies

  1. Sprint

         Sprint is a predefined interval or time frame in which the work has to be completed and make it ready for review or ready for production deployment. This time box usually lies between 2 weeks to 1 month. Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.

       A Sprint can be cancelled before the Sprint time-box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master.

 

2.Scrum Team

        Scrum team is a team of 7 to 9 members comprises of the product owner, the development team and a scrum master. In the overall scrum team there is no team leader who assign the task to team rather whole scrum members work as a team & they decides the task on which they will work on. Also the problem will be resolve by team.

3.Product Owner

      The product owner is the key stakeholder or the lead user of the application to be developed. The product owner is the person who represents the customer side. He/she has the final authority and should always be available for the team.

       He/she should be reachable when anyone has any doubts that need clarification. It is important for the product owner to understand and not to assign any new requirement in the middle of the sprint or when the sprint has already started.

4) Scrum Master

        The Scrum Master is a servant-leader for the Scrum Team. He/she makes sure that the scrum team is productive and progressive. In case of any impediments, scrum master follows up and resolves them for the team. SCRUM Master is the mediator between the PO and the team.

           He/she keeps the PO informed about the progress of the Sprint. If there are any roadblocks or concerns for the team, discusses with the PO and gets them resolved. Like the team’s Daily Standup, a stand up of the SCRUM Master with the PO happens every day.

 

 

5) Business Analyst (BA)

        A Business Analyst plays a very important role in SCRUM. This person is responsible for getting the requirement finalized and drafted in the requirement docs.

        If there are any ambiguities in the User Stories, he/she is the one who is approached by the SCRUM team and he then takes it up to the PO or else if possible resolves on his own. In large scale projects there may be more than 1 BA but in small-scale projects, the SCRUM Master may be acting as the BA as well.

6) User Story

      User stories are nothing but the requirements or feature which has to be implemented. In the scrum, we don’t have those huge requirements documents, rather the requirements are defined in a single paragraph.

7) Epics

        Epics are equivocal user stories or we can say that these are the user stories which are not defined and are kept for future sprints.

         For example imagine you are going for a vacation. As you are going next week, you have everything in place like your hotel bookings, sightseeing, travellers check etc. But what about your vacation plan for next year? You only have a vague idea that you may go to XYZ place, but you have no detailed plan. An Epic is just like you next year’s vacation plan, where you just know that you may want to go, but where, when, with whom, all these details you have no idea at this point of time. In a similar way, there are features which are required to be implemented in future whose details are not yet known. Mostly a feature begins with an Epic and then is broken down to stories which could be implemented.

 

8) Product Backlog

        The product backlog is a kind of bucket or source where all the user stories are kept. This is maintained by the Product Owner. Product backlog can be imagined as a wish list of the product owner who prioritizes it as per the business needs.

        During the planning meeting, one user story is taken from the product backlog, then the team does the brainstorming, understands it and refines it and collectively decides which user stories to take, with the intervention of the product owner.

9) Sprint Backlog

         Based on the priority, user stories are taken from the Product Backlog as one at a time. The Scrum team brainstorms on it determines the feasibility and decides on the stories to work on a particular sprint. The collective list of all the user stories which the scrum team works on a particular sprint is known as Sprint backlog.

10) Story Points           

           Story points are a quantitative indication of the complexity of a user story. Based on the story point, estimation and efforts for a story are determined. In order to make sure that our estimate and efforts are correct, it’s important to check that the user stories are not big. The more precise and smaller is the user story, the more accurate will be the estimation.

            Each and every user story is assigned to a story point based on the Fibonacci series (1, 2, 3, 5, 8, 13&21). Higher is the number, the complex is the story.

11) Burn down chart

               Burn down chart is a graph which shows the estimated v/s actual effort of the scrum tasks. It is a tracking mechanism by which for a particular sprint the day to day tasks are tracked to check whether the stories are progressing towards the completion of the committed story points or not.

12) Velocity

            The total number of story point which a scrum team archives in a sprint, is called Velocity. The Scrum team is judged or referenced by its velocity. Having said that, it should be kept in mind that the objective here is NOT achieving the maximum story points, but to have a quality deliverable, respecting the scrum team’s comfort level.

______________________________________________________________________________________

By

KRISHNAGAYATHRI GOPINATH

REFERENCES: