#Agile #Estimation #Sizing explained in a more simple way so that it can be understood easily

1. Estimation of the user stories in agile project had been quite a difficult task for project management and so do it is
more complicated for the scrum team. There are multiple reasons on why the estimation of the user stories seems to
be complicated. To understand more better on what could be the limitations and issues team would face while
estimating, let look in more fruit-yyy way.
Project Vision: Consider project where the vision is to consume different varieties of edible fruits (yes correctly read..
fruits) so that it can be correlated with different constraints which impact the estimation. Also let us consider these
are not known product which is the ideal case for any project. Given this vision and the user stories which are listed
as fruits, let us see what are the various constraints and how they can be handled.
User Stories: Product Owner defined the user stories the way it is mentioned below
PO has clarity on what the user stories and the acceptance criteria. The acceptance criteria for all of the user stories
is to consume all of the user stories with 0% wastage.

2. Estimation guidelines:
Similarity / Size: The very first aspect team can consider is
similarity of multiple user stories and see if their
correlation exists, also content of the user story. Since PO is
part of planning activity will be supporting in team in
guiding the process of understanding the similarity of the
user stories. In our example, let see how the relative size
and similarity exists for different user stories. Per these
criteria, it can be understood that on size plum, walnut
seems to be small and jack-fruit seems to be large, also
walnut, plum and grapes are similar and so it can be
differentiated.

3. Estimation guidelines:
Duration: If the user stories to be classified based on the
duration that would be required to complete, as PO is
being an integrated part of scrum team could define user
stories which would help team to understand what would
be duration of the task. Team would then be able to
identify how much duration would each of the task
required to be complete, let see how does this applies to
our backlog.
Complexity: Team most of the time will think of how
correlated the user story is when compared with other
related work it may have delivered earlier, this correlation
will help to understand if the task involved is complex or
simple. Complex user stories would mean higher story
points when compared to simpler stories, in our case based
on the description from the PO and conversation team can
figure out that grapes/plum would be simpler to consume
and jackfruit would be more complex.

4. Estimation guidelines:
Uncertainty: In some cases, user story seems to straight
forward and can able to decompose them to smaller task
straight forward. There would some user stories where the
work is known but when start to decompose the
uncertainties would evolve which the team may not be
aware of earlier. PO may clarify that jackfruit may contain
200 seeds/slices but then when team starts to work may
uncover it contains 250 or more, this would mean the story
would take more time and so do the points. Team must
consider this while estimating and consider this factor
while sizing.

5. Estimation guidelines:
Expertise: Agile strongly recommends having cross cultural
team for any project to be successfully executed. Multi-
talented teams often out-perform monolithic team on
execution since they have all of expertise built in. Consider
in our case not everyone may be expert in carving out
jackfruit or pomegranate but someone relatively better in
doing this job. As in agile task are pulled by the team rather
being pushed, these experts will come out and get this task
pulled. This self-organizing concept will bring out real
expertise to work critical task to support team in focusing
on deliverables and achieving it. So based on expert
judgement, we can identify the quantum of work each of
the story may require and size accordingly.

6. Estimation guidelines:
Infrastructure: For any user story to get complete team
should ensure require infrastructure exists prior to
committing it for sprint. The more the infrastructure need,
the more size of the user story it would be. Some user
stories may not require any additional infrastructure based
on which team can size that to be small but then for some
stories it may be too huge infrastructure would be required
which will then be of larger size. So as the team discovers
from PO, that Jackfruit may require more sophisticated
tools for faster execution, team may then need to allocate
team to ramp-up on these tools and so do the size of user
story grows.

7. Team while estimating the stories may be not doing these
classifications on paper but would be considering it will sizing. As team
had analyzed the user stories on these aspects and start sizing, our
estimation may look this for the product backlog
Just to wrap up on how the
project would be delivered, let
consider the velocity of the team
of 4 be 5 story points and we have
total story points of 65 would
mean the project will end by 13
sprints. If each sprint is of
duration 8 minutes (per say) our
project of consuming all of the
user stories would be 104 minutes
which would mean 1 hour 44
minutes…yummy…