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 1: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 2: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 3: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

Fabricio Laguna talks Business Analysis and AI
I recently connected with Fabricio Laguna, aka The Brazilian BA. Fabricio is a passionate and pioneering business analyst from Brazil. During our conversation, we had a thought-provoking discussion on how artificial intelligence stands to shape the field of business analysis in the years ahead. While AI promises to transform many aspects of busines...
Business Architecture, Ontology and More with Terry Roach
It's been a privilege meeting Terry Roach, a visionary in the field of enterprise architecture and business architecture. Terry's insights into the evolution of business models, the importance of ontology in architecture, and the potential of AI to shape our future were not only thought-provoking but also a reflection of his extensive exper...
Today I had the pleasure of chatting to Jignesh Jamnadas, Chief Operations Officer at Mosaic, about his Blueprints for Success. As a Senior Finance and Operations Executive, Jigs (as he is known to many) has a holistic understanding of all facets of business and a flair for managing both people and processes. Having worked with Jigs, I was struc...

 



Upcoming Live Webinars




 

Copyright 2006-2024 by Modern Analyst Media LLC