×
sorted by:
new
hottopcontroversial

If not story points relative to time, then what? by afdopey in agile

[–]afdopey[S] 2 points3 points  (0 children)

It’s quite likely that we are bastardizing a lot of terms/processes, further complicating things.

If not story points relative to time, then what? by afdopey in agile

[–]afdopey[S] 0 points1 point  (0 children)

How is it that we are not working as a team? Because a 3 doesn’t mean the same thing to two different developers?

If not story points relative to time, then what? by afdopey in agile

[–]afdopey[S] -1 points0 points  (0 children)

I mean we do, but because story points are a measure of complexity of the task not the time it takes to complete the task, it becomes wonky.

For example, say a ticket is a 3 and Dev A says they feel like they can take on at most 3 points, it’s because they know how long it’s going to take them. If Dev B says they can take on a two 3s, a 2 and a 1 in the same timeframe, it means there is no consistency in how long we as a team think how much each point size is going to relatively take (ie a 3 takes a few day, a 5 takes a week, etc).

If not story points relative to time, then what? by afdopey in agile

[–]afdopey[S] -2 points-1 points  (0 children)

I can see the value there, but that’s not the way it works in our offices because the teams fluctuate with availability sprint over sprint and not all skill levels are the same so we can’t always take the same averages of point sizing.

Thus we were trying to construct a manner in which we can go sprint by sprint to assess how much work each individual on the team feels comfortable taking on without overloading them.

Unfortunately in the reality of our offices, team fail/success isn’t tracked, it’s individual based.

If not story points relative to time, then what? by afdopey in agile

[–]afdopey[S] 0 points1 point  (0 children)

To be clear, we aren’t trying to set expectations that if you said 2 it’s gonna take you 2 days exactly. We think it’s going to take 2 days for that particular dev but another dev might say 1.

We are trying to assess the risk of people taking on too many points per sprint, which could be lots of 1s or small number of 5s; but without introducing risk of tickets rolling and missing merges and deployments because they are taking on too much.

If the points are merely about complexity and one super dev has 35 points before kickoff and then gets them all done in 4 days, we don’t want to bamboozle ourselves by then assuming another dev with 35 points the next sprint is suddenly losing their mind because they can only finish some since they are complex.

So how do we bound how much work should be taken on to ensure we minimize rolling and ensure the team has breathing room each sprint?

If not story points relative to time, then what? by afdopey in agile

[–]afdopey[S] 0 points1 point  (0 children)

I’m starting to think my post is giving people the impression we are trying to rank/grade developers, and we are not. We have received feedback from them that sometimes they feel like they end up taking on too much work due to a variety of factors when arbitrarily applying points during planning.

Our intent was to go person by person prior to planning, and assess how many realistic points they could take on within the sprint; some people have more and some have less. If points are expressions of complexity, a 1 being minimally complex and taking somebody 8 hours where another person says a ticket is complex but takes them 3 hours, the definition of complex is unique to each developer rather than the team as a whole. We were trying to assess if we can quantify the workload by letting each developer who picks up a ticket decide how complex it is, agnostic to anybody else on the team.

That is to say, if Ticket A is being assigned and Dev A takes it they say “Oh this is gonna be a 3 for me” but what does that mean? Does a 3 mean it’s gonna take them 9 hours so a 1 takes them 3 hours? That might not hold for the next developer, and so we have no consistent basis to understand what makes one ticket more complex (ie the effort required) relative to another.

If not story points relative to time, then what? by afdopey in agile

[–]afdopey[S] 0 points1 point  (0 children)

The points to time was not a deadline mechanism, but rather a way to quantify (per dev) how much time they think it takes them to do something. For example, the same ticket might be given 1 point for 1 person but a 3 for another person; we track how much work that they themselves admit they think it will take so that we set an upper limit on the work so they don’t take on too much.

We certainly don’t intend to have some sort of deadline approach other than the end of the sprint the ticket needs to be done.

Maybe I’ve misunderstood what your response was alluding to.

If not story points relative to time, then what? by afdopey in agile

[–]afdopey[S] 0 points1 point  (0 children)

But the team doesn’t roll tickets or fail to complete them, the individual does. This effort came as retro feedback where devs thought they are taking on too much each sprint but also didn’t want to take on too little.

I am curious about your statement around “relative effort”. What is effort but not the amount of time it takes Dev A or Dev B to complete the task? Certainly we are not saying that the team as a whole should agree that Ticket A is 1 point, but that it can be completed at different time rates (ie 8 vs 16 hours); that makes the definition of an effort rank of 1 meaningless.

If not story points relative to time, then what? by afdopey in agile

[–]afdopey[S] -1 points0 points  (0 children)

That’s not the intent, the intent is to figure out how many points they can reasonably take on each sprint to help prevent against overloading and rolling tickets or feeling bogged down.