[Scrum]Task estimation inputs
Posted by Plastic_Scale3966@reddit | ExperiencedDevs | View on Reddit | 18 comments
Recently a new PQA lead(Process Quality Assurance lead) (I didn’t even know such roles existed) joined our team , they also participate with a bunch of other teams .Recently during an estimation call, they asked all the Frontend members of team to estimate Backend work. The FE devs are purely FE and the stories are purely BE .
Has this been a common practice in your organisation or is this some bs that I’ll have to just deal with ?
iamgrzegorz@reddit
Planning poker decks usually have "?" card, I would encourage people who are unfamiliar with the particular task or the codebase it touches to just use it and say "this is outside of my area of expertise, I trust others can estimate it better"
Plastic_Scale3966@reddit (OP)
this is the ideal thing to do, but there’s a lot of factors involved in out team that just rule out doing something like this. almost like corporate dictatorship :/
JunketSuch4062@reddit
Yeah, this is a classic scrum theater 😄
They are likely trying to follow a textbook rule that the whole team must estimate everything. But forcing pure FE devs to guess BE work just leads to meaningless, made-up numbers and wastes everyone's focus time.
My team and I ran into a similar management rule that slowed us down so to push back, we started tracking these exact process frustrations on an easyretro board during the sprint. The second a meeting or a rule breaks a dev's focus, they log it, and we sync it directly to jira
Having that hard data makes it way easier to show leadership that their new process is actually hurting efficiency, helping you protect the team's deep work time! : )
Plastic_Scale3966@reddit (OP)
you have a cool team
TomOwens@reddit
I'm very familiar with the concept of process quality assurance and dedicating people to this type of role, but this situation doesn't make much sense.
Quality assurance, in general, is about ensuring that both the product or service offered and the processes used to deliver it are consistent with requirements, that any problems or incidents related to the product or the execution of the processes are resolved, and reporting is available to key stakeholders. The requirements they focus on could be legal or regulatory requirements based on the industry of the developing organization or its customers, organizational policies and procedures, or requirements derived from customers and users of the product or service. Some organizations split quality assurance into product quality assurance and process quality assurance, since there may be nuances or details essential to performing the task.
I wouldn't necessarily expect someone in process quality assurance to tell your team how to work, though. If there is a requirement (such as an organizational procedure, for example) that says that all team members are to be involved in estimating all work and they observe that isn't necessarily happening, I would expect that to be captured as a deviation and a discussion about the right way to handle it. There are at least two ways to handle this: updating the procedures to match how the team works or changing how the team works to match the procedures. I would expect that discussion to happen with the team - in the case of a team implementing the Scrum framework, the Sprint Retrospective is the perfect opportunity for that to happen.
Personally, I would want to eliminate steps from the process. Estimation, especially at a task level, is waste. Waste should be eliminated from mandatory process steps. If a specific team finds estimation helpful, nothing prevents that team from imposing more process steps on itself. However, failure to implement organizational process controls would be a non-compliance in an audit or appraisal setting.
Plastic_Scale3966@reddit (OP)
this PQA lead is just another typical micromanagement freak, and they’re from that one country - hope ykwim . I didn’t add a lot more details coz i didn’t want this post get removed for violating rule 9 .
there’s a lot of frustration in the team regarding this, I could go report them , but I don’t fully trust my teammates to back me.
But thanks for helping me understand about PQA , that’s very useful and I wanted to know. I’ll update here if something good comes out of this situation
diablo1128@reddit
The teams responsible the work are the ones you participate in pointing a story at all places I have worked.
Also points are suppose to be effort and not time estimates. So in your case the FE people would just have higher points because it would require more effort for them to complete a story in the backend.
aomame23@reddit
Maybe it's to give BE devs a much larger cushion? Are you always behind on deadlines? FE devs will sandbag estimates because they dont have the context or knowledge on tickets. Not something I would complain about
Plastic_Scale3966@reddit (OP)
no, they don’t want the teams to have cushion of any sorts. If some dev estimates higher than most, they will be asked to explain themselves
ginamegi@reddit
Is your team a mix of frontend and backend devs?
If so are you saying that your team divides its work among the devs based on who has the best expertise in it, usually front and backend being the division?
Then there’s the problem. Your management brought in someone to try to enforce half-assed scrum that you guys weren’t doing “by the book” in the first place.
What’s happening here only works if the team is truly cross functional and anyone can be empowered to pick up any work. “By the book” every team member should be participating in pointing every story during refinement. But you guys are somewhere in the middle and that means it won’t make sense.
That’s the core problem with scrum and why it gets a bad rep. You kinda have to admit you’re not doing it or truly follow it line by line by the book, and no one does that.
perdovim@reddit
That's the fallacy of scrum, everyone is equal and able to play every role.
The reality is we're all humans. Different people are good at and enjoy different things. Some are good at making good UIs others are good at databases, ... It is a rare person who is equally good at all.
I like scrum, and have run many teams. The fastest way to ruin any development paradigm is to put The Process ahead of the people doing the work and trying to force them to bend to It. Process is important, it ensures repeatability and predictability. But it needs to be tempered with the knowledge that it's humans involved and we have particular different skills that have to be blended to get a good product out the door...
Plastic_Scale3966@reddit (OP)
No, we only have pure frontend and pure backend devs.
teink0@reddit
It is probably to remove the silos and dependencies. What is the reason for the front end / back end schism? Is anything stopping single person from do the entirety of a change, front end back end or otherwise?
Plastic_Scale3966@reddit (OP)
our team only has pure frontend and pure backend devs . When stories involve both FE and BE , everybody will estimate . But lets say there’s a refactoring story for Backend, how would Frontend devs have a solid idea of the amount of work needed?
ginamegi@reddit
You estimate it higher because you can only estimate based on the knowledge you have. “I’d give this 5 story points because I’d need to research the infrastructure since I don’t have experience with it”.
Plastic_Scale3966@reddit (OP)
fair enough
lphomiej@reddit
No, we use estimation to... ya know... estimate how long it'll take to do something. The fidelity of the estimate helps you determine how much you can probably do each sprint. So, the person doing the ticket is usually the one who estimates it -- or maybe like "planning poker" to let multiple people share different perspectives/warnings/etc. In any case, it's people who know how to do the work estimating it to give the estimate the best chance possible.
Plastic_Scale3966@reddit (OP)
thats right , i’ll push back next time