How long will it take to get this done?

When can you release this?

It’s a frequent question for anyone who works in a product organization:?how long will it take to get this done??Rather than replying “it depends”, it’s helpful to give the requester an idea of the process a request traverses to end up being something that “gets done.” This won’t stop the question, of course. It will spark a fruitful discussion to discuss where things are rather than rely on an imaginary delivery calendar.

Here’s an example of a process to follow to evaluate requests, ensure that bugs and escalations are handled, and build a pipeline of work ready to be completed and evaluated by developers. It’s not foolproof – there’s no process that survives first contact with customers – and it’s a good place to start in defining the workflow of stories and issues through your organization.

A quick word: processes are meant to be living documents, not set in stone.

Is the thing you found a critical, work-stopping problem?

Whenever you start a basic triage, it’s important to figure out whether this issue is a widespread or critical problem. If this is true, “when’s it going to be done” takes on a special case as you ought to be all hands on deck to solve the problem. If you think you’re facing a critical problem, make sure to have at least one other person test that they see the same thing. After confirming, feel free to leap into action.

In most organizations, critical problems don't happen nearly as often as things that people observe that they'd like to see fixed. Most of the time, issues that come up in the “so, when’s it going to be done” conversation fall into these groupings:

1. A new thing the customer has asked for
2. A new thing that’s come up in conversation
3. A brand new idea from a team member

Whether it’s a net new idea or a tweak to an existing feature, it’s always important to know the specific improvement in the context of the user’s request.

What were they trying to do?

What did they see on their screen or in their other process?

What happened that was unexpected?

The more information you get, the easier it will be to understand the request. (When you explain this issue to a developer or another person and you get a blank stare, that's a good signal that you need to provide more context.)

Is this a request a “Good Idea”?

Not all ideas are good ones.

All of this initial discussion will serve to label your issue and determine if it is a Good Idea. This is a loaded judgment and is really specific to the way your organization handles problems.

Some of the ideas that will show up in this process are not ideas that you intend to follow through on. There are also ideas that may not seem fully formed that get through the ideation process and turn out to be pretty good. There needs to be a process or a general standard to indicate whether ideas are good because it costs money and time to process these ideas to get them closer to development.

“Good ideas” tend to be aligned with:

• increasing the ability of the ideal customer to use your software, particularly in a way that increases the usability and simplicity of getting stuff done
• fixing an obvious deficiency that stops the user from doing something intuitive
• a novel capability currently missing from the product that is aligned with the types of problems users want to solve

The definition of a good idea will definitely shift over time, though it ought to be related to the basic DNA of the product and should make sense when you compare it to existing features in the product.

Is it a good idea that we are already working on?

If this idea is good, we might already be working on it. In a product or success org, it would be nice to think we don’t create duplicates. But this sometimes happens. When you find a duplicate, it’s important to compare the new idea to the one already in the process. You might find new wrinkles in a feature or an important nuance that needs to be included.

And each time you review an existing idea, ask yourself whether it makes sense to work on this idea over another idea. If an idea or request comes up often, it’s a sign that users are encountering the same problem repeatedly.?A product enhancement might not be the only way to solve this issue. Test your assumptions and ask if there’s another way to achieve the goal.?(Pro tip: search your list of issues and you might find things that look familiar. Your team will thank you.)

When you are setting the internal priority, keep in mind that there is probably another solution to the issue you are raising. Workarounds usually exist to a customer request. They are often complicated, brittle, and hard to complete. And they can be the best option for right now. If there’s no workaround, the idea is good, and it sounds like the kind of idea we should be working on, it’s time to move it to the next stage.

Note:?an idea can be great and it may not take precedence over another thing we’re working on simply because we’re trying to move an entire body of work into a stage where it can be worked on by a developer.

Ok, let’s write a story to make the idea better

Once you have solidified the problem and the need, this information needs to be written out in a formal way to ensure that the rest of the team knows what to build. A user story is a form of writing out the requirement to let us know the critical elements of what to build when we are discussing a solution to a problem. We want to answer questions like:

1. Which user or kind of user are we building this for?
2. What is the expected behavior, including the entry and exit behavior?
3. What kinds of actions trigger changes, and are they directed by a user or by an API or a different system?
4. Is this a reversible change, or does it trigger a change that cannot be undone?
5. What typical error conditions might occur and how should the system respond?
6. How will we measure the usage of this feature?
7. How does this feature fit with other systems that we have in place?

A successful story will answer many of the questions an implementer will have about building the experience it suggests. It will identify open questions that come up during the discussion. And stories will not be complete without visual illustrations that show what to build next.

Would someone who has never heard our explanation understand this idea from a picture?

Stories alone usually don’t let us know what to build. A picture is worth (at least) 1000 words. In the context of a feature story there are a few different kinds of illustrations that will help in the review process:

1. a basic illustration, showing the labels and basic flow of the feature. This is necessary for having a discussion and initial estimation.
2. a pixel-perfect rendering of the feature as it would show up in the product. This is expensive and should be done when you’re sure what to build as the last gate to making items ready for review.

Detailed illustrations along with user stories are the key to pitching a feature the rest of the team can evaluate and help you determine if the feature is ready for development. Because the stories and the pictures don’t always translate into a package that’s completed. When this happens, keep doing this loop until you answer the relevant questions and are ready to go.

Yes! We're ready for development

Features that have been reviewed, have well-maintained stories, and have practical illustrations are ready for developers to pick them up and work. That tells you what you could work on. It doesn’t tell you the order or the scope of what you should be working on. That’s because the build process is dynamic. It’s related to the market, your roadmap, and the way your customers want to use your product. “Ready for development” is a state of mind where you continue to stack work that is relevant, aligned, and detailed enough to deliver results.

What’s the takeaway??Getting work done is a continuous process. Following a process to take in new work, develop it so that it can get reviewed, and stack that work in a development pipeline aids in creating a productive backlog of work. It also helps you answer the question in your organization of “how long will it take to get this done.”