Getting Started with Agile-Scrum Methodology- Introduction: Part I

Share this Post

Scrum is Agile methodology which is most widely and commonly used in the software industry. The methodology is a part of Iterating and Incremental methodology and is best suitable for projects that have a highly changing nature and rapidly emerging requirements.

There are many other project management methodologies, but Agile – Scrum is the most popular as it puts together a self-organized team with max 7-9 members. There is no direct project manager. Instead, there is a scrum manager to guide the team on best scrum methodology practices to get the maximum benefits. There is also a product manager who provides clarifications and requirement prioritization. I will explain the roles of Agile – Scrum in the latter phase of this article.

SPRINT is one of the key terms used in Agile – Scrum methodology. It is simply a series of iterations. The timeline of a Sprint is usually 2 weeks to one month.

BACKLOG is like a bucket where all the necessary functionalities that the team arrives at (after brainstorming or feedback from stake holders, or feedback from client discussions) are kept for reference. The product manager and the team will decide on how to prioritize the backlog, and the high-priority items will be used in the implementation.

USER STORY is a simple and understandable manner of writing the requirements. It contains 3 main parts in the following format:

As an <Actor> I want to <Action/Result> so that <Outcome>

Example: As a <project manager> I want to <generate the resource burn down chart> so that I can <plan my estimate for the next week>.

The software development life cycle (SDLC) contains several steps and Agile – Scrum encapsulates almost all in it.

A ‘Requirement Analysis’ happens without heavy documentations or complex use cases, via user stories. In other project management methodologies, the requirement analysis imposes a huge burden on a business analyst. This also includes the time that he/she spends on documentation. However, in Agile – Sprint, the development team, the quality assurance team, and the Scrum Master all brainstorm on the product backlog item that is prioritized by the Product Owner, which takes the pressure off the business analyst.

After that, the teams break the epic story, or the product backlog item, into user stories of manageable sizes to be addressed in a particular sprint. The team cannot make the design in advance, but will design the system in pieces and as the functionalities grow, the design and the architecture of the system grows as well.

Implementations happen efficiently as the team is cross functional and contains developers, database engineers and technology experts. Testing plays a vital part and the Scrum team has QA engineers for testing and test automation.

STORY POINT is also a common term used in Agile – Scrum. Every user story is given a Fibonacci number (Ex:0, 1, 1, 2, 3, 5, 8, 13, 21) based on its complexity. A highly complex user story will get 13/21 whilst a medium complex story gets 5/8, and a low priority, simple story gets 1/2/3. The team decides on the story point to be given for a user story and this story sometimes differ from QA members to the developers. The team then agrees on one number that is accepted by everyone.

The total of the story points achieved within a sprint is called VELOCITY. The project team is normally measured by this number.

Communication is key in Agile – Sprint, just like in every project management methodology. The team conducts a SPRINT STAND UP MEETING every day for about 15 minutes. During this meeting, they discuss:

  • What was addressed the previous day
  • Team plan for today
  • Possible obstacles

After every sprint, the team needs to integrate the new functionality to the core system and describe it to the product owner and the stake holders.

Feedback should be encouraged. However, addressing the feedback will need to be prioritized. If it is urgent, it can be dealt with immediately, but if it can afford to wait, it can be entered in the product backlog and addressed accordingly.

Feedback should be always welcome though addressing again needs to be prioritized and if the feedback needs to be addressed as soon as possible go for it else put it to the product backlog which the team can always pull when time permits.

BURN DOWN CHART is an artifact of Agile – Scrum that displays what is left to be done. The burn down chart can be drawn using story point vs. sprint or actual vs. estimated for the sprints. Sprint planning is a vast area that I will address in my next post.

Poornima Fernando
Business Analyst – Project Delivery