Skip to main content

Story pointing in very first sprint for new project

Last post 06:43 pm May 21, 2019 by Ian Mitchell
4 replies
03:02 pm May 21, 2019

Ours is very new project and we are starting a sprint from tomorrow. 

We don't have base stories to compare and decide estimation (relative estimation) for stories we are planning for new sprint.

In backlog grooming meeting today we went by following approach- :

1 story point = Simple

2 = Medium

3= High

5= Complex

8= Epic (Can't be completed in a single sprint)

Now, since we were not having any stories to compare we went by development team's gut feeling . 

Is this the right way ?

We were just having 3 stories in this sprint , out of which for 2 stories developers gave 5 points and to one story 3 points. There is a possibility of exploitation of freedom by development team in a way that for 3 story points they may say 5.

So, we need to create a base for relative estimation. 

How should we create it ? I hope my question is clear.


05:01 pm May 21, 2019

Vishal,

I think your approach is very good.   Have the team make their assessments on size (best guesses) for the first few sprints, and then review what items they identified as 3's, 5's, etc.   Are they consistent?   Were there outliers, and if so, what were some of the reasons for the inaccurate estimation?

Your "baseline" will evolve after a number of sprints.   Allow the team over time to develop consensus around how they relatively size items.


05:01 pm May 21, 2019

Now, since we were not having any stories to compare we went by development team's gut feeling . 

Is this the right way ?

Absolutely.

I would suggest you use T-Shirt sizing this early in the game. Small, Medium, Large, XL, XXL. Get used to using this kind of estimation and then move to actual points. Your team will find the base as they continue to work on the product. In 3 months, what the team said is a 5 now, may be a 1 or 2, or it could be an 8 or 13. It is a relative number after all. Encourage the team that there is going to be failure along the journey. They will say something is a Small or 1/2 and mid-sprint it turns out to be much larger; that's okay, it's part of the journey. Go 3 sprints and then ask the team what they think of the story point structure and then compare the done stories to stories needing to be sized and see if they found their base line. 


05:19 pm May 21, 2019

My coaching has always been that you can't change something until you do something.  In the case you are posing, I think you did the right thing.  You need to start somewhere and refine the practice as you acquire more data points.  The team arrived at a starting point for their scale and used it. 

...we went by development team's gut feeling . 

Even when you have done this 1000+ times, you will still be going by the team's gut feeling. An estimate is basically an educated guess. I have never seen a way to make this a formula or exact science that is reliable.  That has been a challenge for many years and none of the methods I have ever been part of were completely accurate. The hope is that over time the team's gut feelings start to become similar which helps them forecast the work that they feel can be done during a time-box.


06:43 pm May 21, 2019

8= Epic (Can't be completed in a single sprint)

By this, do the team mean that they can’t complete 8 points-worth of work in a single sprint, or they aren’t prepared to invest 8 points-worth of work in just one item, or something else?


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.