1

Agile estimating and planning

Estimation based on the concepts of agility involves valuing each item on the prioritized backlog

and determining how much effort will be required to complete each one. Estimates are difficult

to get. In order to get estimates for completing priority tasks, agile estimation is used. It is often

done by calculating how long it will take to do the job. Teams that use agile approaches make

estimates with relation to narrative points. In Agile projects, a story point is used to evaluate the

complexity of executing a particular user story. It is estimated in relative units based on the

number of user stories that have various levels of estimation required.

A summary of this definition is that a narrative point is a statistic that aids in estimating the

complexity to effectively create a user story. While it may be a problem linked to complications,

dangers, and effort, the issue could also be something else (Mahnic, 2011). Strong cooperation is

another benefit of project estimate based on Agile principles. Project X provides an idea of the

amount of time to expect if project Y is part of the project. Developers tend to overestimate and

underestimate, which results in— development and launch timelines always being delayed.

However, although the process is complex, setting up Agile estimate when the project is in the

early stages helps with accurate user story estimations and facilitates the consistent delivery of

relevant features. Agile estimation methods have clear, quantifiable results such as:

1. Improved Decision-Making

2. Better Coordination

3. Better Risk Management

Stages of Agile Estimation

1. Conduct Stakeholder Interviews

 2

As part of the discovery process, the BA assigned to the discovery team will review any existing

documentation provided to see if there are any gaps or questions that were missed during the

original creation of the documentation. After a year, the BA holds workshops with stakeholders

to address and answer any questions about the workflow of the system. The BA collects the

business and functional needs from these sessions and develops them. The ultimate objective of

the project is defined in the Business Requirements Document (BRD). Defining the key

characteristics of the end objective is an important part of the functional requirements document

(FRD). It is possible to conduct these seminars over the phone or in-person with the customer.

2. Define High-Level Product Backlog

Next up is the phase of Agile Estimation when BA, with the Technical Architect, comes into

play. They provide stakeholders a specific goal that they want to be accomplished, and then offer

a possible solution or product. At the highest level, the product backlog consists of stories that

represent the main features of the program. Once it is verified that the backlog is addressing the

scope of the project for the customer, a validation is done.

3. See who the customer is and who the potential customers are

The most complicated problems may sometimes need that a UX design anchor be included,

especially if they are meant to address issues for a large group of people. The key objective for

the UX analyst is to both understand the client and the consumers they are targeting. A user

experience analyst designs personas for the users of the system, the context in which those users

will be using the system, and the methods through which the users will communicate with the

system. There will be ecosystem maps, personas, user journeys, and storyboards to be included

in the deliverables.

4. Prioritize Requirements
 3

Once confirmed by the stakeholder, the discovery team begins working on the high-level

backlog. Prioritization is used alongside the analysis to determine which requirements to fulfill

immediately, those that can be worked on later, and those that must be dropped. The MoSCoW-

based backlog items are categorized into three groups: must-haves, should-haves, and could-

haves.

5. Prepare the Minimum Viable Product (MVP) Backlog

The BA gathers the required needs into “must-haves” for the backlog and proceeds to identify

and prioritize those requirements for the MVP development. It is possible that in addition to the

"should haves," the MVP backlog may also include a few things from the "want to haves" list,

which is intended to ensure that the product is adequately competitive in the market. Budget and

timeline considerations may mean skipping this stage, and the agile teams will go straight to final

product development.

6. Estimate the Project Cost and Timeline

According to the discovery team, the anticipated time and cost for the initial release is calculated

based on the backlog of discovered items. Finally, the process includes a Build, Rinse, and

Repeat phase until we get with a ballpark estimate for the company's requirements. In addition, it

enables for features to be loaded and unloaded based on the point in time when product

development begins.

Agile Velocity

Agile projects use the concept of iteration and velocity to estimate how much work can be done

in each phase of the project. A very popular timeline-building application is widely employed as

a tool to help development teams produce accurate and efficient schedules. Velocity in Agile is

measured relative to the needs of the team who are measuring it. Agile velocity is meant to be
 4

used mostly as a planning tool, but maintainable consistency is an important goal. Agile velocity,

or iterations per unit of work, is simply a calculation measuring the number of work items that

have been completed within a set time period (Bumbary, 2016). Engineer hours, user stories, and

story points all serve as different methods of measuring units of work. Since timelines are

typically measured in iterations, sprints, or weeks, it applies to all three.

Agile velocity analysis by itself provides little insight. Rather, long-term trends can help one

assess and improve their organization's Agile efficiency. Agile does not intend for velocity to be

used as an efficiency goal. It is a simple but common misconception that many people make:

When a team's velocity drops, they wonder, "How can we get it back up?" Developers may be

forced to compromise quality in order to meet a deadline.

In other words, if Agile velocity is decreasing, there may be underlying issues that need to be

addressed. If one is certain that there are no limitations, they should anticipate moving at a

slower pace. This change would improve timeline and budget accuracy.

Moreover, higher Agile velocity numbers must be monitored. A drop in quality may indicate a

hasty team. If this is not the case, and one can achieve higher velocity than expected without

compromising quality, you may be able to shorten the overall timeline. A "trend" is not always

positive or negative. While both can help one identify areas in the development process where

they can save time while maintaining technical quality, one will need to dig deeper to find out

more.

Differences between Burn up and Burn Down

Other popular project visualization options include burnup charts. Burnup charts and burndown

charts are in the same coordinate system, with the only difference being that burnup charts
 5

represent elapsed time instead of activity. But, a burndown chart lets you see how much of the

work remains and a burnup chart lets you know how much you've completed.

A burnup chart starts from the bottom and climbs upward, rather than using burndown charts that

go down. In addition to the "main" scope line, burnup charts will also display a separate line that

denotes how far your product is from the requirement. When a project is going well, the progress

and scope lines of the burnup chart intersect at the end.

In comparison to traditional burndown charts, burn-down charts excel because of their focus on

simplicity. Burnup charts, on the other hand, display more information and can give you advance

warning of changes in scope. When the iteration is finished, a burn-down chart will only register

changes in features and scope. You can plan for changes in scope and meet the deadline with

burnup charts.
 6

References

Bumbary, K. M. (2016, April). Using velocity, acceleration, and jerk to manage agile schedule

risk. In 2016 International Conference on Information Systems Engineering (ICISE) (pp.

73-80). IEEE.

Mahnic, V. (2011). A case study on agile estimating and planning using scrum. Elektronika ir

Elektrotechnika, 111(5), 123-128.