Handling detailed feedback from many sources

Question

In software development, when you near the time for delivery, there's often a huge amount of feedback. Testers report bugs, customers ask for minor and major tweaks, designers have last-minute improvements etc.

One solution is to make each feedback item a separate story (in JIRA or on a kanban board, for instance). However, then you end up with a huge and unwieldy list of things where nobody really gets the full picture.

In addition, some of this feedback will arrive when there's no real forum to make priorities - say you have a priority meeting with the customer on Tuesday, you're due to release on Friday, and you get a rush of feedback on Thursday.

What are some good ways to handle this?

Answer 1

In software projects, whether they be waterfall or agile projects, there is a development lifecycle of some form. For Agile projects, usually, these lifecycles are broken up into tiny versions of the waterfall model.

At some point before you're release, what you need is a feature freeze. No more new features will be added to the release. This means design improvements, additional features, and you must hold all stakeholders accountable and be prepared to say "no", even to the client. Don't actually say "no" though. Instead say, "We are planning to implement that for you in the next release. We want to stay on target for release 1.0 and want to be sure to provide you with a quality deliverable."

With that said, this is then your time to focus on bugs. Again, bugs aren't new features, and bugs aren't design improvements.

However, bugs are defects in the software that were introduced that were not part of the spec, and the spec includes both functional bugs as well as bugs in the usability of the software or the designers original design.

First, consider that part of a Web designer's job is to think about how the user is going to interact with the software. The best designers put quite a bit of thought into every minute visual detail, and they engineer the user interface the way they do for a reason. Their goal is to make people want to use the software, and I've personally seen the same product sit stagnant, with poor usability, or throttle its number of users into the stratosphere with good attention to detail.

In my experience, developers don't always see this perspective clearly and sometimes don't implement the UI correctly. Therefore, it's up to the project manager to work with the team (designers and developers) to determine what the highest priority is for the immediate bugs, the ones that must be fixed prior to release, and the bugs that, when fixed, will help ensure success of the release.

Answer 2

First of all if you have a release on Friday, and you received a list of changes from customers on Thursday you have to decline them or decline the release time. Obviously that changes what were added at the last minute can't be stable. After that we have reports from QAs and designers. Well, we definitely pay attention to QAs' reports than designers' ones. It's because QAs' reports have our mistakes and problems, when designers just added some graphical improvements. Only one situation when we have to look designers' reports it's when those reports have fixes for our graphical mistakes, not improvements/changes. Hope it helps.

Answer 3

the other answers you've gotten are right on the money, and the advice holds true for any domain, not just software.

It comes down to priorities, and actually 'managing' the project. At some point you're going to have to ship, so as you approach that point you need to be clear on what the priorities at that point are. In you example - the bug reports take priority and have to be fixed. That's part of the original scope, and quality control. The major & minor tweaks - those get sent through the Change Control process to evaluate their impact and let the client decide priority. That's a scope change and not necessary to release. And the "last-minute improvements"? Sorry, you had the whole project duration to come up with that. As Jmort said - next iteration.