2022 | Research Artifacts

Qualitative Surveys: Requirements & Team Satisfaction

Summary: This document outlines a series of suggestions on how to improve the product development processes at […] and increase harmony between departments.


After an acquisition and introducing new software development processes, it became increasingly clear that there were issues at […]. To help identify and resolve these pain points, I was tasked with investigating and auditing the processes teams were using.

Proccess Pains & Resignation

Eventually, process problems wear down employees, reducing their morale, and in many cases, driving them to resign. The turnover rate at this company’s tech roles is especially high, and resignation is not exclusive to new hires. Even tenured employees exit because of these problems.

In the last sixteen months, these are some of the roles that have resigned from […] product team.

Role Resignation


-1 Director of Development


-1 Quality Assurance Lead


-2 Senior Engineers


-2 Engineers


-2 Product Managers


-2 Scrum Master

Some of the frustrations employees experience are even made public. Past employees have posted their feedback on Glassdoor, which could potentially deter talent from entering teams. If enough negative feedback on the technology teams makes it online, […] could develop a reputation as a place for top talent to avoid.

glass door review
another glass door review

True Cost of Requirements

Unclear and changing requirements take up time—each phase in the development journey requires an increasing amount of resources to resolve.

The cost of change chart represents the challenges teams are currently facing. Constantly, development teams are being asked to work from unclear requirements. This results in delayed feature releases, shipping incorrect solutions, limited sprint output, wasted time spent on re-working, and even contributes to the high turnover rate for tech positions at […].

If […] were to take action and resolve the issues with requirements, the rewards would be exponential—product teams would be able to deliver higher quality work faster that drives customer satisfaction.

How Teams Are Effected

Working under these conditions is not only inefficient, but it’s also frustrating for team members. When surveyed, employees report that their assignments are unclear and lack details.

When work is assigned to me, product requirements specs are clear, detailed, and informative

7 Responses

After work has been assigned and started, requirements remain accurate

7 Responses

I feel happy with the current product development process for my team

7 Responses

Current and upcoming priorities are clear and easy to predict

7 Responses

I feel confident in the performance of my team and their reliability

7 Responses

Additional Comments

6 Responses

There needs to be more design, collaboration, and discussion when a business presents a request. Additionally, we need time to revisit our tech debt and developer experience. I feel like things are heading in the right direction and improving but […] has never had a process in place for our lifecycle that leads to quality solutions.

Have clear requirements that have been thoroughly reviewed and approved by all stakeholders (executive, biz, UI/UX, product) before they are delivered to the scrum team. Switch to Kanban or another simplified process until we get a predictable, working process. Eliminate the product roadmap until product proves they can do their job.

We need to be sure that stories are fully detailed with specific and clear requirements before they get to the development team. The dev team is not responsible for the "design and implementation" of features and enhancements. They need clear direction outlined in the stories so there is no question that we are delivering what the business needs, not what we think they would want.

The numbers wouldn't change drastically if I were less frustrated. We have legitimate issues that are and will continue to plague the development team.

Building a dedicated product design team

I'm frustrated but still enjoy the challenges of the job, and believe I can make a difference and help turn things around.

How to Implement Change

Committing time and people is usually difficult within large organizations—at […] it’s nearly impossible. Getting product leadership, C-level executives, and stakeholders all together at once turns into a wild game of calendar Tetris.

scheduling calendar event

Working in cycles drastically simplifies this problem. A cycle gives teams a standard project size both for shaping and scheduling.

team track diagram

shaping team overview

batch overview

Starting Options

Overriding the current processes and changing everything teams currently do is an enormous amount of unnecessary risk. Instead, this should be a process tested, validated, and operated separately with a small team.

Option A: Six-Week Experiment

  1. Shape one project that can be comfortably finished within six weeks.
  2. Carve out one designer and two programmers’ time for the entire six weeks. Guarantee that nobody will interrupt them for the length of the experiment.
  3. Plan for the team to do the work you shaped for this one experiment.
  4. Kick-off by presenting shaped work to the team. Set the expectation that they will discover and track their tasks.
  5. Dedicate a physical space or a chat room to the cross-functional team so they can work closely together.
  6. Encourage them to get one piece done by wiring UI and code together early in the project.

Option B: Start with Shaping

Sometimes, getting teams together for six weeks is impossible. Instead, try shaping a project with clearer boundaries than past projects. Present the project and put it through your company’s existing software development cycle.

Better-shaped work can shine a light on the engineering team and help them open up to things like longer cycles or a more deliberate betting process.

Option C: Start with Cycles

Another approach is to start by working in six-week cycles. For teams familiar with two-week sprints, this removes the workload of constant planning meetings and gives programmers more time to code.

Once the team has more bandwidth, it’ll be natural to think about how to shape the work to take advantage of this new capacity.

©2023 Tyler Renfro