I'm a small business programmer. I love solving tough problems with Python and PHP. If you like what you're seeing, you should probably follow me here on dev.to and then checkout my blog.
Right. Your team is presumably filled with smart, capable people. But even smart people have a tendency to make suboptimal decisions when the deadline is approaching.
It's something I'd address at your retrospectives. You are doing retrospectives, right? Learning from your actions? Making your team stronger? Etc.
Anyway, people get in a rush and stop doing the things they know need to be done to create working software. But, we also know that it's very expensive to fix a missing requirement when you catch it in testing. Different studies come up with different numbers but 10 to 100 times is not unreasonable.
Just bringing up that cost should be enough to get people exciting about spending a little more time making sure you haven't missed any major requirements. But some teams will need more convincing, which is okay too. If that's the case, you're next step is to begin measuring the cost of missed requirements. Just keep track of it and report it at your retrospectives.
The number is typically huge. And once you see how wasteful missing requirements are, you can't unsee that. Then you just schedule some time for searching for missing requirements at the beginning of your planning instead of in testing. And keep track of that too.
So, now you have a running experiment. You can turn the "hours of searching for missing requirements" knob to whatever your team thinks is reasonable and observe the change in "hours of fixing missing requirements" value. And if you are working in short intervals (sprints) you'll soon optimize that value precisely for your team.
Does that make sense?
What do you do to actually find your missing requirements? Let me refer you to Software Requirements by Karl Wiegers and Joy Beatty. If you have a requirements question, this book likely has the answer.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Right. Your team is presumably filled with smart, capable people. But even smart people have a tendency to make suboptimal decisions when the deadline is approaching.
It's something I'd address at your retrospectives. You are doing retrospectives, right? Learning from your actions? Making your team stronger? Etc.
Anyway, people get in a rush and stop doing the things they know need to be done to create working software. But, we also know that it's very expensive to fix a missing requirement when you catch it in testing. Different studies come up with different numbers but 10 to 100 times is not unreasonable.
Just bringing up that cost should be enough to get people exciting about spending a little more time making sure you haven't missed any major requirements. But some teams will need more convincing, which is okay too. If that's the case, you're next step is to begin measuring the cost of missed requirements. Just keep track of it and report it at your retrospectives.
The number is typically huge. And once you see how wasteful missing requirements are, you can't unsee that. Then you just schedule some time for searching for missing requirements at the beginning of your planning instead of in testing. And keep track of that too.
So, now you have a running experiment. You can turn the "hours of searching for missing requirements" knob to whatever your team thinks is reasonable and observe the change in "hours of fixing missing requirements" value. And if you are working in short intervals (sprints) you'll soon optimize that value precisely for your team.
Does that make sense?
What do you do to actually find your missing requirements? Let me refer you to Software Requirements by Karl Wiegers and Joy Beatty. If you have a requirements question, this book likely has the answer.