Skip to main content

Story points in team of different seniority levels

Last post 12:21 am January 14, 2020 by Sherwin Soriano
7 replies
04:32 am January 11, 2020

I learn now how to use poker planning but my team has different seniority levels

There are 3 associates and 2 principals and 2 seniors

For each one of them the complexity is way different

If for example a story point for an associate is 8 and for a senior is 5 and for the principal is 3

How can I determine the number of points in this case

Should I go with the highest which is 8 ? Or the median which is 5

 


09:33 am January 11, 2020

One big advantage of relative estimate using Point is the capacity to have collective estimate, mostly with mixed level/skills.

A small item is small for everyone, being a junior or an expert. Let's say this is worth 1 point. Of course, if the junior is working alone on this small item, she will work on it for 5 hours where the senior will take 1 hour, but anyway, it still is 1 point.

But the junior will not probably work alone, right ? And the expert will use a lot of her time to help other, right ? So nobody can know actually how many hours it will take for the team, and we really don't care.

A big item is big for everyone. So big than 1 point could be 5. A bigger could be 8.

No need to make calculation.


12:57 pm January 11, 2020

Story points aren't typically used in this way. Story points tend to be related to effort or complexity. Regardless of who does the work, the effort or complexity will be the same. However, I would expect more experienced people to be able to expend more effort in less time because of their knowledge and experience. All of this means that the team should normalize their story point values on effort and not time. As the team gains experience (particularly in learning the context in which they work, understanding the stakeholders, and building the product with the selected tools and methods), the time it takes to complete work pointed at as an 8 becomes less and the team can accomplish more points per Sprint (increasing their velocity).

What I describe is why story points are highly volatile. The meaning of "1 Story Point" changes between teams (and even a team can decide to renormalize what it means within that team) and the amount of story points delivered per unit of time changes with the understanding of the problems, updates to the Definition of Done, team composition, knowledge and experience, and other factors.


02:21 pm January 11, 2020

How can I determine the number of points in this case
Should I go with the highest which is 8 ? Or the median which is 5

Why settle for a workaround? Planning poker is intended for use by a team of peers, such as a Scrum Development Team. Wouldn’t it therefore be better to try and actually resolve the issue of formalized seniority? In other words, wouldn’t it be better to address the cause of the dilemma the team faces as a result of hierarchy, rather than one of the symptoms?


06:55 pm January 11, 2020

Is it a good idea to pick one example story and have a common agreement on its story points and keep that story as a standard reference for planning poker estimator for the team ?


11:27 pm January 11, 2020

Wouldn’t it therefore be better to try and actually resolve the issue of formalized seniority? In other words, wouldn’t it be better to address the cause of the dilemma the team faces as a result of hierarchy, rather than one of the symptoms?

@Ian Mitchell, Titles and seniority will exist in organizations even if we choose to consider no official titles in the team other than Development Team member as per Scrum. Unless this seniority actually becomes an impediment for the team, it should not be a problem right? In the case of what the OP is asking how would we come to a resolution if a less experienced developer considers a PBI worth for ex 5 points vs a more seasoned developer who considers it only worth 2? Should we choose 2 or 5? As in the case explained by @Olivier Ledru, the whole team can come to the same conclusion and a more experienced developer may/can spend some of his/time with the less experienced developer to get the PBI to Done.

In that case, It is my opinion that it would cause a sense of bias where the more experienced member can justify the reasoning for estimating a lower story point and therefore drive everyone to select the lower value in the next round in case if there were differences in the first round for the same PBI.

Even, I am curious what the right approach in this case is. @Olivier Ledru, @Ian Mitchell Would you be able to help clarify? Thanks.


05:32 pm January 13, 2020

I have presented this analogy a number of times in this forum, so I will simply list a couple links below to access my posts on this subject.

What is very important to remember in story point estimation is that the time to complete should not be a consideration.   We should only be looking at the effort and complexity of the item.   

To use my analogy, you are basically asking your development team members to move a boulder from point A to point B.   Some Development Team members may be stronger than others (principals, senior level), and can move the boulder quicker.   The boulder never changes shape, size or weight though based on who decides to move it, does it?

Focus on the boulder, and not on those being tasked with moving it!

More on the boulder analogy (point A to point B):

https://www.scrum.org/forum/scrum-forum/31862/story-points-complexity-vs-effort

https://www.scrum.org/forum/scrum-forum/6861/what-velocity

 


12:21 am January 14, 2020

@ibrahim, you should not go with either 8 or 5. The team should discuss and decide on that one.

Remember also that these are only estimations. I have encountered some structures where they tie the quote as a form of appraisal which is very bad (e.g. 2 SP = 2 days, if dev did not finish on 2 working days, they are tagged).


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.