I think the author misses what the purpose of deadlines is. They are contracts between organizations for when software will be available, which are used for other organizations to make informed decisions without needing very tight and constant communication. They're analogous to SLAs in service-oriented designs.
In a moderately large (say, 500+ employee) organization, deadlines are essential to get anything done. Suppose, for example, you're overhauling a billing system, making international tax calculations simpler. The finance team is making a hiring decision: they need to get tax stuff calculated before the end of the year; do they need to find consultants to help them with this, or is the software going to be ready in time?
If your answer to them is "I can't tell you, we just do stuff on the kanban board and don't think about deadlines," they're
(1) going to be less than thrilled with you, decreasing trust, and (2) unable to make their decision effectively.
I don't think "there's only "stuff" to be done" is an adequate alternative to deadlines and sprints if it doesn't address the reason organizations use those tools. They're primarily tools for predictability and scaling outbound communication about progress; I think the author mistakenly believes they're supposed to be motivational tools. They're sometimes misused that way, for sure, but that's not the whole picture.
No, the idea is that you don't set hard deadlines for the team - they're pointless. It results in unnecessary stress and work won't get done any faster (maybe in the short term, but it's unsustainable).
Either the deadline is too short and your team has to work overtime, or it was too generous and you lose efficiency.
The project manager, of course, still needs to be able to make an estimate according the his team's velocity, which he can then communicate to other business divisions.
“One of the most controversial updates to the 2011 Scrum Guide has been the removal of the term “commit” in favor of “forecast” in regards to the work selected for a Sprint. We used to say that the Development Team commits to which Product Backlog Items it will deliver by the end of the Sprint. Scrum now encourages the Development Team to forecast which Product Backlog Items it will deliver by the end of the Sprint. It may seem to be a simple wording change, but in fact there are strong reasons behind it.”
Pretty sure the Scrum folks are aware of needs of enterprises and their deadline addiction.
Yes - sprints can be a great estimation tool as long as they aren't mistaken for a deadline or performance measurement.
In my opinion, it needs be more like drawing a (rough) "this is how far we will get at the current velocity" line somewhere in the sorted backlog, rather than a fixed set of tickets that you expect to get done.
Popular tool-driven "agile" workflows where you move tickets into a particular sprint, followed by the admission of defeat at the next sprint planning meeting when you failed to complete all of them, reinforce the idea of "commitments" rather than "forecasts".
> No, the idea is that you don't set hard deadlines for the team - they're pointless.
I think the issue stems more from the prevalent confusion between deadlines and milestones in part of the IT world.
I used to work on ship command system. The ship would be stopped for maintenance for a couple of months and available for installation and qualification only during this set period of time. Anything not ready for this window would not be delivered. That's an actual deadline which the project had to meet.
As a project manager, it was my job to keep track of my team milestones to ensure we would be ready for the deadline and find solution when we had issues. It's not only about overtime by the way. You might need a temporary increase of the size of the team, access to external resources, time with an expert or a scope adjustement. Sometimes it's just impossible to meet the deadline and you just want to know as soon as possible to reschedule at minimum cost.
You do need to make an estimate in order to plan your milestones but you also need to commit or you will never know if you are on the right course.
>The project manager, of course, still needs to be able to make an estimate according the his team's velocity, which he can then communicate to other business divisions.
PMs who can successfully and reliably handle this kind of analysis and forecasting for their team are more rare even than high-end software developers (in my experience in nyc startups, may be different elsewhere). And they can be far more expensive, because these skills apply heavily to things outside tech as well, so you're competing in a larger employer pool than developers.
The reason, I think, that (immature) companies use these sprint/deadline frameworks is that it puts the entire burden of everything complicated onto the engineers (estimation, forecasting, figuring out how to meet deadlines, incremental delivery, progress communication, GANTT charting, road-mapping, etc). They focus all their budget on hiring "good engineers" and then try to localize all the "hard" stuff there within engineering, and then they decide they can skimp and hire underpaid former consultants to be "product managers" where all they do is check boxes on a requirements list, and play the telephone game between deployments and engineering. It's literally creating the role of that guy in Office Space - "I'm a people person." These people will also never be able to gain enough control of product direction to challenge anyone in leadership over anything.
Company leaders seem to have some vague notion that this will somehow all work out in the long run by framing this whole thing as "being agile," and "not sinking too much resources into things that will change," yet all it is is lack of proper project planning abilities and a fear of owning risky decisions. It's a culture utterly lacking in leadership accountability. If everything is "wait and see," or, "ask the engineer for a commit- cough I mean 'estimate' for when it'll be 'done'," then nobody can ever be held accountable for bad leadership decisions or for improving their decision making skills over time as they learn and grow in a leadership position at the company.
I know this comes off kinda conspiracy-theory-esque, but I have a feeling that many of these systems develop in order for the less-skilled-but-scrappy initial engineers/employees who were friends of the founders to retain control as the company grows and develops the resources to hire far more skilled (but more risk averse) employees. Far too often you have someone who is perfect as a founding engineer and VP of Tech for 10-15 initial developers, but does not grow their experience to match the exponential growth of the company, so they do NOT have the experience to be CTO of a 100 engineer tech team several years later if the company takes off. But now this person has been through "war stories" with the founders/C-Suite, and the other execs can't bring themselves to realize that the person is now a huge burden on the company, because the other execs are also mostly in over their heads as well at this specific point in time (high growth).
One good way to judge if this is the case at a company is to see if they have an "engineering IC career ladder" and see what skills they decide apply to "senior" IC engineers. It very often ends up being things outside engineering that appear at the higher rungs of the ladder, even though it's supposedly an "IC" ladder, because they can't figure out how to hire the proper roles for those things, and can't do them themselves. It's crazy to me how many people seem to think a very experienced engineer should be working on GANTT charts and roadmapping instead of systems architecture design & maintenance, and high-complexity-scale technical change management, not to mention R&D and onboarding/training.
Not conspiracy-theory-esque at all. Great insights. You sound like a more sane and balanced version of michaelochurch. Maybe you are extrapolating too much from a limited set of experiences, but your basic logic seems sound.
I've spent most of the first few years of my career working for small startups, or teams where I was the only dev, so I've seen lots of engineering projects "managed" by people who don't understand engineering. I was quite capable of self-managing, so it was often frustrating being straightjacketed by someone who didn't really know what they were doing.
I wasted a lot of time and probably would have been better off in a larger start-up or company with proper engineering management and a defined career track.
There are two kinds of deadlines: the ones imposed by objective facts (like for example the Y2K deadline), and the ones imposed by arbitrary decisions (like for example a milestone in a project plan). I think it is important to distinguish the two.
There's also a 3rd kind of deadline and they're the worst kind. It's the "our sales team have already told the customer it will be ready by then so you need to tell me how you're going to achieve that" deadline.
I can deal with hard technical deadlines and project milestones - the former is a fact of life and the latter is often required to help focus larger projects. What I emphatically dislike is sales guys making business decisions before checking with the engineering teams to determine how much effort is required to deliver a project.
I used to dislike this too, mainly because they put the problem in your bucket.
The solution is to not let this problem end up on your side. "We will see what we can do, but since we didn't make any estimate on this, the risk of failing the deadline is on you. If you want to set a proper deadline next time for my team, consult me first so we can do a proper estimation. I hope it works out for you this time."
I also had plenty of cases where we had to reach an imposed deadline. Then 2 weeks later you ask "did they find issues?". "No, they didn't deploy it yet"
This isn't something you can get away with in many businesses (at least not in terms of the kind of businesses that would put you in that position to begin with) - and the few you can do this, it's not something you'd want to do frequently because you can end up being seen as an obstruction and that ultimately works against your interests.
I've found it's better to work with them on a compromised phased released / MVP so the customer still gets what they asked for and you are still seen a miracle worker albeit without actually having to do anything unrealistic in the end.
Unfortunately though, there are some businesses that place their sales team too far ahead of the health of their engineers for any compromise to happen and there isn't really much you can do aside taking the overtime pay and move on shortly afterwards.
> you can end up being seen as an obstruction and that ultimately works against your interests.
I always worked in small companies < 200 people, so this might be different in bigger ones.
If you are the competent software engineer that always delivers quality software, and is always pushing the company towards a better and more progessional way of working, you will not easily be seen as an obstruction. I never was, and always had good to excellent reviews.
A sales person that sucks a deadline out of their thumb is in no way to be seen as professional. Questions such as "who estimated this? Was anyone from software development involved? Did you account for testing? Do you expect the custommer to find all our bugs?" Etc, should reveal that there is another way of working.
I had a sales guy respond to me "I've been doing this for 30 years, so I know". This guy was fired half a year later
Sales people setting deadlines without consulting the people that need to do the work, is very unprofessional, and there is no way that anyone can defend that. You just have to make this very clear, in a diplomatic but clear way.
It sounds like we’ve had very different experiences but from what I’ve seen I think it depends more on the management / CEO than the company size. Some of the smaller companies I’ve worked for have been worse than any of the larger companies and that was entirely down to the fact that the CEO saw the sales team as the money bringers because they scored the lucrative deals, where as the engineering team were seen as replaceable work horses.
But as I said, the best thing you can do in those sort of places is take the money and move on because you aren’t going to change the CEO’s attitude.
Changing the CEO's attitude is indeed impossible, even with multiple people that he respects.
If you are seen as a replaceable work horse, you lose a lot of leverage indeed.
Here in Belgium there is a huge shortage of software developers, which places the programmers in a stronger position than the companies.
I can leave a company and instantly get the same or a higher pay somewhere else.
A company on the other hand, first has to find somebody, and then still overpay the first few months before the new employee becomes productive. From that point it's a bad position to be in.
There's definitely a shortage here as well. But that doesn't mean that a CEO has respect for the trade.
My thinking is if a CEO comes from a sales background then they will run their company in that mindset. Much like how some CEOs who are developers sometimes struggle to release products because they're focused on the technology rather than the product (gross exaggeration there - but I hope you understand the point I'm making)
Usually when you set an arbitrary deadline, it quickly becomes less arbitrary. See OP's example of the finance team depending on a certain timing that they were promised.
> If your answer to them is "I can't tell you, we just do stuff on the kanban board and don't think about deadlines," they're (1) going to be less than thrilled with you, decreasing trust, and (2) unable to make their decision effectively.
I think the point is that if you do make those commitments you are just making things up, in reality those commitments are worth pretty much exactly as much as not making the commitments.
Where with reality I mean the actual physical reality. I realise that social reality can be different, and even a commitment that you make despite everyone knowing that you don't actually have any basis for making that commitment (no track record, no reasoning, no nothing...) can be valuable.
>I think the point is that if you do make those commitments you are just making things up, in reality those commitments are worth pretty much exactly as much as not making the commitments.
Well, reality is not that harsh and there is a middle ground. It definitely is possible to complete things on schedule. Assuming "cost, time and scope - choose two" as a reasonable model, there are trade-offs you can make to get the thing out in time.
What the OP argues, and I fully agree, is that it's unsustainable for people to work with deadlines all the time. But I think that discarding deadlines entirely can be competitive suicide. There is a way to put in place deadlines in particular strategic circumstances, assuming (again as the OP implies) you have some control of either scope or cost.
That's not a reasonable model though. You cannot pick "time+scope". As has been well documented in software adding money to a project does not necessarily make it move any faster.
Also, there's a theory that projects take the time you give them.
There are some deadlines that are too short that can't be hit, but if you have a project your team has done before in 4 weeks and give them 8 weeks, it'll take 8 weeks. The reason is it can always be improved. There are always more edge cases and more automation that can be added. Plus, many people would gladly work at half speed rather than full speed if the outcome was the same (daily compensation, praise, success, etc.).
I have $1,000,000 in the bank. I have 10 engineers. If we don't make at least a break-even income in 6 months I have to fire 10 engineers. So you have 2 months to build something so I can spend 4 months hyping people up to buy a bunch of it or we close down. And I know your engineer asses ain't gonna write bug-free code.
Given that the amount of communication grows exponentially with the number of people working on the project maybe you could rent out 5 of the engineers and make the project go faster :)
I'd simply say that if something isn't ready, then as a general rule, don't make decisions as though it will be ready at a particular time in the future.
For instance, buying a home thinking that a new highway will be done around the time you move in could lead to multiple years of disappointment. Voting to allow your city to provide substantial financial incentives could enable the builder to go to extraordinary lengths to get the project done at the appointed time.... but even then, only within reason.
Survival bias: companies that guess poorly aren't around to explain why they believed they were being reasonable.
...to expand a bit: you're more likely to benefit from correct forward looking estimates if you have sound alternatives available when those estimates to be less than completely accurate.
Is there evidence for this? There are some very real examples of software companies that thrive by not providing estimates, valve, blizzard, google, apple, etc. I would assume the dominant factor in software delivery is actually ability solve user problems and not being able to time when those problems will be solved.
The author deeply misunderstands Scrum. They also misspell it as SCRUM but that's another story...
Sprints are timeboxes and not deadlines. Stuff is done at a "normal" pace and it either fits (or does not) in that timebox.
Fundamentally, it does not really matter in itself. Noting down whether the estimation was correct or not, though, is important.
The whole point is that a team is supposed to get more _predictable_ over time. They learn how to estimate better, and having a fixed "box" to fill is a very easy way to do so.
So: Scrum is a "scientific" way to reach a sustainable pace ("scientific" meaning: based on objective, repeated measurements).
This is not to say that Kanban does not work. It's just way way harder to do right, because measurements of how good a team is at having a sustainable pace are not as intuitive and are easy to ignore for teams -- and ignore it they do, unless they are very well disciplined.
But all of this is well know in the world of Agile, I remember talking about this ten years ago. Perhaps an agile coach would truly help this person.
As an aside, "sprint" (which obviously implies moving at the greatest speed possible for a human on foot, pushing themselves to a point which cannot be sustained for long distances) is pretty poor terminology for something meant to represent something happening at a sustainable pace. I'm sure I'm not the first or last person to point this out, though.
When I first heard the term “sprint” I thought it was surely being used so they could later make some point like “since sprinting is of course unsustainable, we introduce weeks of relaxation between them”... Nope!
Me too. I actually proposed 3 day sprints at work Tuesday-Thursday. With Monday and Friday being for meetings and nonsense. They laughed at me like I was joking.
Most people who say they are doing Scrum or think they are doing Scrum aren't really. Scrum is far from perfect but it's better than most of the bastardizations people invent for themselves when they claim to be doing it.
At some point if most people are following your framework incorrectly it might be time to acknowledge that the framework is hard to implement correctly.
If your proposal for fixing it is for people to try harder to do it correctly then you might have a bad framework.
This nails it for me. I have seen too many scrum implementations give insufficient weight to pointing, leaving it undecided whether the pointing scale is linear or something else, pointing inconsistently across people within a team, and most importantly not accounting for when reality differs from estimates over time. IMO this leads to foregoing one of the most important benefits of doing scrum in the first place.
I really hope I'll live long enough to be in the Scrum project that's run this way. In all the companies I worked for Scrum with its sprint and daily stand-up meetings just becomes a tool for micromanaging the team.
EDIT:
My own understanding of Scrum was, that you can commit to a deadline for the whole project (say, we'll have this application ready by the end of Q3), and then use sprints and backlog prioritization to manipulate the project scope. So, when you hit the deadline you always have ready to use product, just maybe with less functionality than intended.
I completely agree with this article. I've worked in scrum and kanban teams and also lead both kinds at some point. To me kanban is by far the better option for the exact reasons outlined in the article.
The point is that deadlines are bad for the people doing the work when they can't influence the amount of work. Not that deadlines should be removed completely, but they should be moved to a level where the amount of work can be influenced, namely project/product management. They should then, completely independently from the development team, adjust the backlog and/or deadlines in case the project schedule starts to slip. If the deadlines are needed because there are doubts that the dev team is not working as hard as they reasonably can then there are bigger issues that any project management method cannot fix.
I find it interesting that in other building projects, like in construction, almost all of the pressure and responsibility for meeting deadlines is placed upon the project management. Not the ones doing the direct labor.
The reason for deadlines in software, they way they are used today, is simply to get more hours out of a week from a software developer. Unlike in construction, software developers do not get paid hourly, nor do they get overtime pay. Abitrary micro deadlines coerce developers to work extra hours which makes their cost per week for amount of work to go down.
In construction, if they made up an arbirary micro deadline that was too short, the workers would get overtime pay at 1.5x their normal rate. Plus the additional hours. So for them, a too short deadline makes their cost per week for amount of work to go up.
We debate endlessly about all these estimates becase we're all pretending its about things that its not. Its almost completely based upon getting more hours per week per developer, as it makes the labor less expensive.
One point of contention for me is the dichotomy between the managers and programmers where one takes care of the "what" and the other the "how" in order to learn "when".
To find a solution within the constrains of this problem-space there need to be made tradeoffs that require creative thinking at every level.
I used to focus on technical work until I realised we where spending millions on projects that go nowhere.
Like in the Dilbert comics its ok for management to wast the time of the developer but a developer should not be allowed to wast his time. It may sound like a cop-out but its much more productive to be able to say, ever so politely, "no this is not something we are going to do".
Kanban is appropriate for maintenance work, but I don't know of too many companies that will invest in a project without at least a general idea of "when will it be done?" and "how much is it going to cost to complete?"
Sprints are about accountability. Estimates are supposed to change based on new information, the understanding being that things change- priorities, desired outcomes, designs, sick time, and so forth. Short sprints are designed to surface new information as quickly as possible, rather than waiting until the project is 90% "complete" timeline wise but only 40% effort wise.
The Dilbert comic shows a false equivalence; management's expectations are simultaneously deadline, cost and feature driven. There is no management technique that can account for all three of those; not even Kanban.
This, so much. If you're missing sprint deadlines, its not necessarily a personal failure as much as a process failure. The solution is to commit to less, to refine your items of work so they can possibly be met in the time you expect. For this to work though, there has to be buy-in from the team members: you can't force it on them.
I've also found that the somewhat artificial sprint goals do act as a good motivation for the team to help each other if they see that the goals might be missed.
There's also the part where you have to be continuously getting feedback and tweaking the ways in which you run the process based on the feedback. If team members feel that this is just another unresponsive management tool designed to get them to work more, it will fail miserably. Instead, if they see it as a construct to provide accountability to stakeholders, they will strive to change and improve the process until it works well.
Ultimately though, the key feature seems to be: the people. If you're not working with a team that's genuinely interested in accountability and helping the product succeed, this process will not work. These are high-trust, highly nimble processes which are completely inefficient if they are actively sabotaged or the promises of good-faith expectations are violated.
If a task cannot be completed within the timeline of a sprint, one of two things are true:
1) The task was not correctly estimated; it is discovered during the sprint that more effort than originally thought is needed.
2) Work that was not accounted for during sprint planning reduced your capacity; things like ad-hoc or unplanned meetings, sick time, peer and code reviews, HR processes, bugs from previous sprints, and so forth.
In both cases, the plan that came out of "sprint planning" does not match reality. I don't consider this to be a failure at all. How people react to it can be wrong, however. "Just get it done anyway", failing to inform team leads / managers when the change occurs, etc are unhealthy, because it creates a disconnect in expectations among the team due to either conflicting understanding of the work being done, or changes in expectations about capacity required.
The 50% is simple math. If your velocity is V, you take V estimation points of work into the Sprint. V is a stochastic variable with a mean and a variance. You rarely deliver exactly V points: it is just the mean. About half the Sprints finish early, and about half the Sprints don't deliver everything on the Sprint backlog.
So this isn't about failure at all: a failed Sprint is one that fails to meet the Sprint goal. I suggest taking a Scrum class to learn how velocity works, how agile works, and to learn how to manage uncertainty (and if you don't admit to this 50% uncertainty, then you are lying to yourself and cooking the books) and to learn about Sprint Goals.
Your post suggests that you understand none of these things. They are all Scrum basics.
It is entirely reasonable for management to set an expectation for two of the three between deadline, cost and features. The whole point of agile, as I understand it from "Uncle Bob", is that as professionals, developers are expected to provide information and guidance based on their professional opinion.
Not only does agile help ensure accountability, but also acts as a continuous feedback cycle for developers to provide new context, information, and ideas as they surface.
I did in fact work at a company that was something of a dev shop for marketing agencies, and it was pretty miserable at times, because they inevitably expected contracts that held to all three. Cost was typically the one thing we could get them to budge on as new information came up (i.e. this necessary feature wasn't accounted for) though who actually ate the cost depended on negotiations.
I don't think I would enjoy working in a business with no management at all, to be honest. There are things that I am good at, and there is a definite perspective from which I view things, and the same applies to good managers, and there is not a complete overlap between the two. On top of that, they deal with problems that, often as not, I'd rather not have to worry about.
Something I've learned in startups is that you've got to have immediate short-term goals and keep pushing towards them relentlessly. In bigger companies with stable revenue the natural sense of urgency is lost, and you can often spend endless time in analysis paralysis or perfecting inconsequential details.
Having milestones and deadlines in whatever process you choose to implement is very important to keeping everyone's eye on the ball. The problem comes in when there is not flexibility for the necessary tradeoffs, and it becomes a death march. This is management failure plain and simple. Taking away deadlines may superficially be better for people's health, but it doesn't help the company be more effective which in the long term could potentially lead to everyone losing their job which is ultimately way more stressful.
Regarding creativity what I found over my time writing code is that you need time to do deep thinking. That’s the only way I know of to harness complexity successfully. Here is the twist: you don’t know how much time you need doing it because you don’t know when realisations emerge. The problem with deadlines is that they create stress and stress is the enemy of deep thinking. The funny thing is that while a deadline can be entirely accurate in estimating the amount of deep thinking required for a task, the mere presence of it prohibits achieving the relaxed state of mind that is required for deep thinking.
Further, having a meeting e.g. at 10am every day (daily standup) means that it’s unlikely you’ll get any deep thinking done during the morning, so that just leaves the afternoon. Adopting daily standups at a fixed time as dictated by Scrum reduces your team’s deep thinking time by 50%.
Another point I've noticed about sprints: It usually creates a problem of "uh we have too much content in the sprint compared to available resources, but it can't be reasonably split into smaller pieces" before the sprint and "uh we didn't deliver what we've overpromised" after the sprint, and people being stressed of tasks always moving from one sprint to another.
Sometimes you have things to do with high estimates (many days) that can't be reasonably split into smaller pieces (the "you don't know what you don't know, and what exactly has to be done" situation). But still, it doesn't look good to put a too highly estimated task in the sprint, so you instead split it into fake "Do X, part 1" and "Do X, part 2", which is basically creative accounting to satisfy the tooling.
In that situation, the Scrum theory says to create a "spike" to figure out what to do, and then create the proper stories, but if often doesn't work this way in real life (in particular, if you need to discover and then deliver ASAP, this doesn't help at all; also often you're in "continuous discovery" mode, i.e. you do stuff, discover what else is needed, and so on, until you're done).
Edit:
A solution to overpromising is to create "bonus" tasks that are kept in the backlog and not put in the sprint, but this lowers the incentive to take them since they're not formally in the sprint (and also who's taking big out-of-sprint items while there's unfinished small stuff in the sprint?)
Adding all the unpredictable things happening during the sprint, basically the sprints are creating more problems than they're solving.
The only good things about them are:
- SLAs for other teams for higher level planning
- a way of saying "no" to incoming requests ("sprint content full, sorry")
This reminds me of an anecdote in the book "Thinking Fast and Slow".
A set of experts (including the author of the book) sat down to complete an education project (like a program or something). They estimated it would take them 1 year, at the most. It took them 7 years.
It is extremely difficult to estimate the needed resources to solve a problem. Especially a problem you have never solved before.
Arbitrary deadlines are unnecessary when there are better ways to manage progress.
You can adopt the product delivery point of view and track progress on something like Kanban board. You track actual deliveries of actual items when they get done and on each time box (eg. 14 days) you open the board and try to understand blockers by looking at kanban columns where items are piling up. If a column grows beyond certain size (work in progress) you should start investigating the reasons evsn sooner. This way you either keep delivering or not and in that case you use periodic sprint meetings to understand why not.
Unfortunately what happens in organizations is that over time the organization based on tracking progress of delivering items or products shifts to tracking work or time workers spent working.
So on periodic 14 day meetings instead of asking questions 'why hasn't this item been delivered yet?', 'what is blocking the progress in delivery?' or 'why are these items piling up in that column?' you get question like 'what is everybody doing and what they plan to do?', ie. typical status report and micromanagement.
The focus shifts from items delivered to work done by people.
As the team then loses focus, managers start to impose deadlines.
It is another case of treating symptoms instead of looking at the causes.
> The tools the development team has for combatting the deadline are unsustainable
This misses the key power of the dev team in Scrum - to say "no":
"Can you do that quicker?" No.
"Can you cut corners?" No.
The dev team may not be able to change features or scope, but they absolutely can tell the product owners to either change things, or accept what the dev team says they can do in the allotted time.
It's like someone that's never painted in their life giving estimates on how long it'll take to paint the interior of a new house based on the total width of all brushes that'll be used and the total area to be brushed. Even if it's small and you'll have a lot of brushes, there could be lots of detail work because of windows/doors/etc.
Who would have a better idea? Probably someone who knows how to paint.
"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.
In a moderately large (say, 500+ employee) organization, deadlines are essential to get anything done. Suppose, for example, you're overhauling a billing system, making international tax calculations simpler. The finance team is making a hiring decision: they need to get tax stuff calculated before the end of the year; do they need to find consultants to help them with this, or is the software going to be ready in time?
If your answer to them is "I can't tell you, we just do stuff on the kanban board and don't think about deadlines," they're (1) going to be less than thrilled with you, decreasing trust, and (2) unable to make their decision effectively.
I don't think "there's only "stuff" to be done" is an adequate alternative to deadlines and sprints if it doesn't address the reason organizations use those tools. They're primarily tools for predictability and scaling outbound communication about progress; I think the author mistakenly believes they're supposed to be motivational tools. They're sometimes misused that way, for sure, but that's not the whole picture.