What is Agile?

Agile could be a project management methodology that's typically used for the software system development. it's a mixture of each progressive and unvaried method for project management and software system development. Here progressive means that work is accomplished in tiny chunks and unvaried means that feedback concerning the work is taken on board before moving forward. it's characterized by the employment of sprint cycles that ends up in frequent review and adaptation of the merchandise and its arrange.

It consists of the many ways however largely start methodology is use most by the software system developers.

let’s ask start.

What is scrum?

So start is largely a framework of Agile. it's easy, light-weight tool designed to assist tiny cross-functional and self organized groups to concur or develop advanced comes. Therefore, let’s discuss some frameworks of start.

1. Roles

2. Ceremonies

3. Artifacts

Role has 3 parameters Product Owner, start Master and Team. Ceremonies consists of sprint designing, sprint review, sprint

retrospective and daily start meeting. Artifacts additionally has 3 parameters i.e. product backlogs, sprint backlogs and

burndown chart.

Before going for these we should always understand the wants of the project that area unit essential for the artifacts.

Requirement Engineering

Requirement Engineering consists of seven phases.

1. Inception

2. induction

3. Elaboration

4. Negotiation

5. Specification

6. Validation

7. Requirement Management

So let’s go one by one

• • Inception: In these part we have a tendency to raise question to the client for understanding the matter statement. what's the domain of the answer and for whom it'll be beneficial? therefore, merely it’s the effectiveness of preliminary communication and collaboration between the client and therefore the developer.

  • Elicitation: we have a tendency to once more check for the wants that has been left within the origination part. We have a tendency to elicit necessities from all stakeholders. we have a tendency to explore for the scope of the drawback; we have a tendency to check for problem volatility.

  • Elaboration: In these part we have a tendency to try and additional specify the main points gather from the higher than 2 phases. We have a tendency to Associate in producing Refine Demand Model(RRM) that's we have a tendency to produce an analysis model that identifies information, perform and activity necessities.

  • Negotiation: In these part we have a tendency to agree on a deliverable system that's realistic for developers and customers. we have a tendency to produce a win-win condition, so everybody might get happy by the given resolution.

  • Specification: In these part we have a tendency to specify the useful and non-functional necessities of the answer. We have a tendency to illustrate the constraints within the means within the type of a come document nor a group of model or a proper arithmetic, etc.

  • Validation: In these part we've a review mechanism that checks for error in content or interpretation, space wherever clarification could also be needed, some missing info, inconsistencies (a major drawback once giant product or systems area unit engineered) and conflicting or impossible (unachievable) necessities.

  • Requirement Management: It merely monitor, track, control, the wants and changes in it at any time because the project proceed. So supported these demand Engineering methods we have a tendency to produce user stories.

What is User story?

A user story is an off-the-cuff, general rationalization of a software system feature written from the attitude of the tip user. Its purpose is to articulate however a software system feature can offer worth to the client. A key part of agile software system development is swing folks initial, and a user story puts finish users at the middle of the spoken language. These stories use non-technical language to produce context for the event team and their efforts. once reading a user story, the team is aware of why they're building, what they are building, and what worth it creates.

Let’s see however its appearance like:

Till now we have discussed about requirements and user story. Let’s go for the Scrum Artifacts that is product Backlog.

What is Product Backlog?

• It is that the list of all demand need for all desired work on the project. Ideally expressed as a listing of user stories in conjunction with “story points”, specified every item has worth to users or customers of the merchandise

• The most significant things area unit shown at the highest of the merchandise backlog that the team is aware of what to deliver initial and therefore the least at the last. the event team does not go through the backlog at the merchandise owner’s pace and therefore the product owner is not pushing work to the event team. Instead, the event team pulls work from the merchandise backlog as there’s capability for it, either frequently (Kanban) or by iteration (scrum).

Estimation and Velocity:

Working in Agile development cycles with the assistance of start helps your team improve processes, increase productivity, and add product worth whereas cathartic updates and new options that your customers want as quickly as potential.

To complete your goals and unleash quality product at a quicker rate, you wish to understand what quantity work your team will complete in a very sprint. This helps you to estimate what quantity work needs to be done before the project is completed. Knowing this sort of data extremely makes it easier to induce the correct team member assigned to the correct tasks and make sure that you have got the resources the team must get the duty done. thus by knowing the time needed to finish the previous sprint, we must always be able to estimate the time for the long run sprint. now estimation is termed as sprint speed.

How to estimate sprint velocity?

Step 1: Count what number user story points area unit completed in every sprint

At the tip of a sprint, add up what number story points the team completed.

For example, assume that in sprint 1:

• The team committed to finishing 5 user stories.

• Each user story had six story points for a complete of thirty story points.

• The team completed 3 of the 5 user stories.

In sprint 2:

• The team committed to seven user stories.

• Each user story had six story points for a complete of forty-two story points.

• The team completed four user stories.

In sprint 3:

• The team committed to 9 user stories.

• Each user story had six story points for a complete of fifty-four story points.

• The team completed 5 of the 9 user stories.

Step 2: Calculate the typical of completed story points

Simply add up the entire of story points completed from every sprint, then divide by the quantity of sprints.

Sprint 1: three user stories x six story points = eighteen

Sprint 2: four user stories x six story points = twenty-four

Sprint 3: five user stories x six story points = thirty

Total = 72

So, your average sprint speed is seventy-two ÷ three = twenty-four.

You can currently base the number of labor to be wiped out future sprints on the typical of twenty-four story points. If you have got one hundred forty-four story points remaining to be completed within the project, you’ll assume that your team can have another six sprints to finish the project.

REFERENCES

https://www.lucidchart.com/blog/how-to-estimate-sprint-velocity

https://medium.com/omarelgabrys-blog/requirements-engineering-introduction-part-1-6d49001526d3