Problem Statement Guide

Try our problem statement guide and ease the prioritization process. Develop a distinct workflow and bring order. Get synched and result-driven. Make your team understand what they do and why.

A Story Full of Pain

Problem statement used to be our weakest point. We wasted hours disputing what we needed to do. Lots of tasks went wrong because of misunderstanding. And the backlog was growing with incomplete issues.

We finally saw the heart of the problem when we decided to start prioritizing. We set up criteria in Ducalis and tried to assign scores to define which of the issues would impact the product the most. And that’s when we realized—the tasks themselves were unclear and impossible to evaluate. Prioritization stopped right where it started. The team was confused and misaligned. Everyone interpreted the tasks in their own way and assigned completely different scores. It was clear that none of us could understand what the team was working on.

Scattered scores are a clear sign that your team is misaligned

So, we decided to put in place clear problem statement rules which we want to share in this article. Yes, we now spend more time on issue descriptions, but they are clear even if you aren’t in the full context of the problem.

The correct issue statement optimizes operating hours and reduces the human factor. The fewer questions you have when reading it, the faster and better you do the job.

General Principles

The development of the project starts with a problem statement.

An issue is a key entity of the job. It defines what you need to do, how you should test it, and what result you should have in the end. Issues are set mainly by a reporter. We do not recommend asking an assignee to state a problem themself. They may not grasp nuances, and their whole vision may differ.

1. Clear and brief

Anybody on the team should be able to understand the problem even if they are outside the context. Go over the text and think about what questions they may have. Answer them straight in the description. Double-check what you have written. Be brief. It’s not a freestyle essay, yet it shouldn’t contain two sentences.

2. Specific and supported

All references must contain hyperlinks to material they relate to. Add screenshots where possible. Attach the existing files (pictures, docs, or similar) an assignee may need. Don’t make people guess or look for data.

3. Readable

Ease the text perception. Help the assignee not to miss some essential points—avoid dense and unstructured descriptions. Use paragraphs, bullets, numbered lists, bold and italic types. Highlight all the essential details.

4. Reasonable

Divide bulky issues into subtasks. It’s necessary for intermediate check points. Otherwise, it may end up with the wrong result. If you can’t divide a complex problem into intermediate tasks, consider if it has a clear endpoint and should be in this form.

Issue Structure

An issue must have several obligatory points highlighted with bold text.

1. Problem

The paragraph describes the problem you must solve within the task. It should be described in sufficient detail for the assignee to understand what they must do and why. The more qualitatively you describe the problem, the more likely the performer will dig it deep enough and offer you alternative solutions.

2. Result

The paragraph describes what the desired result is. The more detailed this section is, the more apparent it will be for the doer to understand what you expect from them and what results they should achieve. For a tester, it describes what to check.

3. Solution or Comments (optional)

You may need this paragraph in case the reporter knows how to solve the problem. Other participants can write their comments here as well.

To wrap it all up, you can spend a whole lot of time selecting criteria that would perfectly meet your product’s values and aims. But to evaluate a task by these criteria, you have to have a clear picture of how it influences the outcome. Can you do that if you can’t fully understand what the task is about?

A well-articulated issue saves lots of time on its evaluation, discussion, and implementation, thus cutting corners of money expenses. It’s better to spend a bit more time on the problem description and think twice than work twice.

Feel free to use and customize our guide. Please share this article if you find it helpful. Let’s make the job easier for each other.

Bonus

We’ve built a plugin with a template based on our guide. It automatically adds Problem, Result, Solution points when you create a new task. Works with Google Chrome+Jira.
You can get it here for free.

Leave a Comment