"how large is the story compare to other stories we had before?" is a better question.
Refinements are a crucial meeting to keep the team aligned and make sure they can collaborate on user stories and help each other.
> How many sick days are there going to be in the sprint?
you don't plan for that.... you only plan for things you know in advance (vacations etc. )
Capacity planning takes less than 5 mins in our sprint planning. not sure where the problem is.
> Is someone leaving or joining the team?
Yep, very important to discuss. in any context (regardless if you do SCRUM or something else).
> people end up confusing sprints to deadlines
End of sprint is a deadline according to definition:
> the latest time or date by which something should be completed.
Because the team thinks it can complete the sprint's stories by the end of the sprint.
It is important to deliver value to customers in a timely manner. This is to lower the risk and prevent multi month/year projects that never go to production, etc.
Sprints help you with structuring your process to achieve this goal. Please keep in mind, this doesn't free the team from thinking how to get the value to the customer as soon as possible.
(You can have sprints and never go to prod...)
> trigger the fight or flight response
If you have people in the team that have that kind of reaction ? Talk about it in a retro, and improve.
SCRUM requires a "save" environment, if you don't have one, almost no sane process will work.
if you don't meet your sprint goals. talk about it in the retro and improve as a team.
Consider, pulling in experience good SCRUM master's the good one's can help how to improve your procceses.
One thing to keep in mind, if the SCRUM is only a thing of one particular department and/or is not fully accepted by the CEO and board, you have some side effects where situations can be quite disappointing and stressful.
however, the scrum master and PO can help sometimes in these situations. If they can't the SCRUM process will be bypassed by people outside (like the CEO) and hence it undermines the process and makes it less effective.
There's nothing about the scrum process that helps me, as an engineer, to work more efficiently. I work at the same pace regardless of what fictional story points are assigned to a task. The entire charade is only for middle managers to communicate up the chain what is happening. Velocity can be massaged so easily that it is a useless metric.
so this means you have implemented scrum not efficiently.
if you work in an inverted pyramid where the team has autonomy (within boundaries) - scrum doesn't become a reporting tool it is for the team. since there is nothing else "above" the team.
The story points are a measure. That help your team to plan a sprint nothing else.
I know how long it takes me to accomplish a task given spherical cows. Since nothing is stable (test environment, content, other fires), the story points are irrelevant.
I was astounded to watch in one organisation while the Software Eng. Manager talked in terms of sprint failure and turned it into a performance issue. That resulted in all sort of unintended consequences.
> Suggesting that meeting a sprint by cutting corners is a thing. Yes, in bad scrum implementations.
SCRUM and KANBAN have both pro's and con's.
If you can't implement SCRUM in a good way, you will also have a problem with KANBAN.
There some good discussions about on online like https://fenix.tecnico.ulisboa.pt/downloadFile/3779576751814/...
> How much effort goes into each task?
"how large is the story compare to other stories we had before?" is a better question.
Refinements are a crucial meeting to keep the team aligned and make sure they can collaborate on user stories and help each other.
> How many sick days are there going to be in the sprint?
you don't plan for that.... you only plan for things you know in advance (vacations etc. ) Capacity planning takes less than 5 mins in our sprint planning. not sure where the problem is.
> Is someone leaving or joining the team?
Yep, very important to discuss. in any context (regardless if you do SCRUM or something else).
> people end up confusing sprints to deadlines
End of sprint is a deadline according to definition:
> the latest time or date by which something should be completed.
Because the team thinks it can complete the sprint's stories by the end of the sprint.
It is important to deliver value to customers in a timely manner. This is to lower the risk and prevent multi month/year projects that never go to production, etc.
Sprints help you with structuring your process to achieve this goal. Please keep in mind, this doesn't free the team from thinking how to get the value to the customer as soon as possible. (You can have sprints and never go to prod...)
> trigger the fight or flight response
If you have people in the team that have that kind of reaction ? Talk about it in a retro, and improve.
SCRUM requires a "save" environment, if you don't have one, almost no sane process will work.
if you don't meet your sprint goals. talk about it in the retro and improve as a team.
Consider, pulling in experience good SCRUM master's the good one's can help how to improve your procceses.
One thing to keep in mind, if the SCRUM is only a thing of one particular department and/or is not fully accepted by the CEO and board, you have some side effects where situations can be quite disappointing and stressful.
however, the scrum master and PO can help sometimes in these situations. If they can't the SCRUM process will be bypassed by people outside (like the CEO) and hence it undermines the process and makes it less effective.