My favourite overengineering story is how much work went into a relatively simple task versus having a high amount of useless output requirements.
The development team had to adopt the primary design role for a pop-up modal on an 'edit profile' page. Super simple, it had some text, some input, and some buttons. The design and UX teams were overwhelmed with other tasks so it fell to us. We created a very bare bones modal that followed other designs already in the system. Very lean, and built with the idea that we would go back to it and improve when needed. However, during the QA phase, I'm pretty sure we had three of the cofounders, all of design and UX, and every developer give an opinion and send it back for tweaking. We probably spent an excess 6 hours fine-tuning this infrequent user-facing popup that was eventually removed.
In addition to DDD, to prevent that adventure from happening again it became important to clearly state the minimum viable "product" of whatever we were building. They're tightly related but still slightly different.
It also became important to make sure that everything needed to build the minimum was available from the start. I feel it violates the agile method because you need to prep for it, but if the perfect design is required to have the feature move to the next phase, and that perfect design isn't ready yet, it shouldn't even start.
Senior software developer at Amazon Web Services. I work on the AWS Serverless Application Repository and AWS SAM. I’m passionate about writing quality software and teaching others how to do the same.
Location
Seattle, WA
Education
BS Computer Engineering, Minors: CS and Math
Work
Sr. Software Development Engineer at Amazon Web Services
Great story. I don't think defining a clear bar for accepting stories into sprints violates agile principles. It's very common to have backlog grooming sessions where there's back and forth between devs and stakeholders to make sure requirements and acceptance criteria are well-defined prior to work going into a sprint. It's a good practice to do things like this to avoid waste due to rework like what happened in your story.
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.
My favourite overengineering story is how much work went into a relatively simple task versus having a high amount of useless output requirements.
The development team had to adopt the primary design role for a pop-up modal on an 'edit profile' page. Super simple, it had some text, some input, and some buttons. The design and UX teams were overwhelmed with other tasks so it fell to us. We created a very bare bones modal that followed other designs already in the system. Very lean, and built with the idea that we would go back to it and improve when needed. However, during the QA phase, I'm pretty sure we had three of the cofounders, all of design and UX, and every developer give an opinion and send it back for tweaking. We probably spent an excess 6 hours fine-tuning this infrequent user-facing popup that was eventually removed.
In addition to DDD, to prevent that adventure from happening again it became important to clearly state the minimum viable "product" of whatever we were building. They're tightly related but still slightly different.
It also became important to make sure that everything needed to build the minimum was available from the start. I feel it violates the agile method because you need to prep for it, but if the perfect design is required to have the feature move to the next phase, and that perfect design isn't ready yet, it shouldn't even start.
Great story. I don't think defining a clear bar for accepting stories into sprints violates agile principles. It's very common to have backlog grooming sessions where there's back and forth between devs and stakeholders to make sure requirements and acceptance criteria are well-defined prior to work going into a sprint. It's a good practice to do things like this to avoid waste due to rework like what happened in your story.