Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Agile Analysis ...  Project Estimation in Agile-Scrum ?
Previous Previous
 
Next Next
New Post 6/16/2016 2:31 AM
Informative
User is offline augustya
1 posts
No Ranking


Project Estimation in Agile-Scrum ? 

Hi,

Can someone here in short describe how Project Estimation is done in an Agile Scrum kind of methodology ? I know there are various techniques like Story Points, T-Shirt and Ficonnacidi and stuff like that but it gets too confusing and boring anyone in short can describe here a generalized way of Project Estimation which is simple, not confusing and is easy to understand. 

Thanks in Advance !

 

 
New Post 8/22/2016 3:56 PM
User is offline hekat0n
1 posts
No Ranking


Re: Project Estimation in Agile-Scrum ? 

Estimation can get messy REALLY quickly. Here's what we do. Each project is given a t-shirt size by Product Management. This t-shirt size is refined as the project proceeds, but we get pretty close with the initial sizing.

Then, the project is broken down by the Product Manager into Epics. The Business Analyst/Product Owner (same person) is responsible for decomposing each epic into stories. If possible, the BA/PO estimates each story in story points.

The BA/PO then holds a grooming session with the team for estimating purposes, where the team assigns a story point value to each story. We know going into it what our anticipated velocity is for the sprint, and that limits how much effort the team can commit to during sprint planning. Any stories that are too large, or too ambiguous, are rejected by the team and the BA/PO refines the story. Rinse/Wash/Repeat.

Here are some of the pitfalls we encounter:

  • User stories too large/too small - fine tuning user story sizes can be tricky. Google "Splitting User Stories" for info.
  • User stories don't provide enough information - this is more frequently-seen on waterfall teams. We have struggled with switching mindsets, but it has gotten better.
  • Story points seem to be arbitrary - this just takes time and experience to overcome. Try setting a baseline for what one point means, then go from there.

I know that this wasn't as short and sweet as it could be, but I'd be happy to answer any questions.

 
New Post 2/28/2017 4:51 AM
User is offline sutnarcha
7 posts
10th Level Poster


Re: Project Estimation in Agile-Scrum ? 

Here is what we do;

 1)      Pick-up a collection of User Stories that belong to the prioritized list of Epics.

2)      Take one story that everyone in the team understands very well and are absolutely clear its deliverable.

3)      To this story, assign any 1 number from the Fibonacci series (1, 2, 3, 5, 8, 13, 21, 34). Now this story is a bench-mark to estimate all other stories you have.

4)      Let us suppose, you choose #3 for the 1 story that everyone understands very well. This means, the story points for the story is 3.

5)      Take another story and ask everyone, if the first one is 3 in size, then what is the second one?

6)      Take voting, bring everyone onto one page if required and finalize the size of the second story (a number in Fibonacci series), in other words story points for the second story.

7)      Move on to another story and finish this estimation of size, always in comparison to the first story, on all stories that are ready for estimation.

8)      Pick-up stories one-by-one in the order of priority for development and testing.

9)      By the end of the sprint, 2 weeks or 3 weeks whatever, sum the story points on the stories that you have completed development.

10)   Now, that sum is the capacity for your second sprint. Most teams prefer to call the first sprint as sprint 0 where capacity was Not known and call the second sprint as sprint 1.

11)   After the end of second sprint, repeat the summing process and take an average of sums from first and second sprints.

12)   Now, that average is the capacity for your next sprint.

13)   After few sprints follow practices like (i ) change the bench-mark story, (ii) calculate average from previous 4 sprints only, (iii) add more factors to the calculation of sprint capacity based on changing team size, growing team knowledge and experience in the project etc.

14)   At any point in time, if you want to give a likely release date to customer for a bunch of epics and their related stories; ( i) calculate the total of all story points on all the related stories, (ii) based on current sprint capacity, calculate the number of sprints required to complete the development, (iii) add additional days for UAT or other phases if any (non-pure-agile) and you get the likely release date.

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Agile Analysis ...  Project Estimation in Agile-Scrum ?

Community Blog - Latest Posts

Digvijaybook
Digvijaybook
IT companies are rapidly looking or adapting modern methodologies, so the business analyst role is increasing day by day. Offline is shifting to online, and this is why today, companies can easily garner important data in any aspect. But, data itself has no meaning hence, organizations look for a business analyst who can analyze the data and draw a...
0 Responses
Digvijaybook
Digvijaybook
Analytics is the future of the business industry. Businesses and organizations today run on data and its interpretation. Its correct evaluation is the fundamental key to success. And business analysts are the guides to it. It is a very prosperous industry and has a lot of potential for talented people. To even qualify, you require more than just...
2 Responses
Samuel02
Samuel02
With the advent of modern-day cloud infrastructure, many business-critical applications like databases, ERPs, Marketing applications have all moved to the cloud. With this, most of the business-critical data now reside in the cloud. Now that all the business data resides on the cloud, companies need a data warehouse that can seamlessly store the da...
0 Responses




Latest Articles

How Will It Work? The Future How Viewpoint...
Dec 08, 2019
0 Comments
The intention of these viewpoints is to make it easier to see and understand the real business problem. This article focuses on the fourth viewpoint, ...
Copyright 2006-2019 by Modern Analyst Media LLC