What happens after “not in this release”?

"No, we won't be doing that in this release" - you've said this to your team before (maybe even had it said to you too).

And it's a sensible answer to a feature request people have. But you have to remember, someone suggested it because they're worried about something, and leaving the feature out doesn't tell us what happens to that problem.

Can it wait? Or have we just stopped talking about it?

And you want people to keep pushing on something like this. But when the response to it is "we'll come back to it", it's just bleh... and that isn't much to go on if nobody knows when that will actually happen.

It's also awkward for the person trying to finish the release too, because hearing a concern doesn't just mean agreeing to build everything suggested in the meeting.

That's what interests me in John Cutler's piece. What he does is separate noticing a possible problem from asking people to act on it now, and suggest keeping those observations somewhere people can add evidence and revisit them.

Then later down the line you might find out that there's no need for a fix at all, which is part of why I like that idea. The bit for me that's still missing is how the question gets back in front of someone. Writing it down is a start, but who's going to answer it?

What do they actually need to keep private?

Alright, for this example, imagine we're on the team building a project-management tool.

A customer already uses it with a small team, where everyone can see every project, and now their finance team wants to use it too. But the customer tells us some of the work that the finance team does cannot be visible to the rest of the company.

Someone brings this up in our design review and suggests we need to build in private projects. Well, let's say we've already planned the next release around improvements for the people using the product, so we decide private projects won't be in this next release.

And then it just gets left there...

The decision has been made to stay on track with the current release and now the new feature request goes in the backlog (I like to call this the "never look at this again log") and then everyone cracks on with building the next release. But this customer's finance team still can't use the tool for that work.

The question is what does the finance team need to keep private, and who still needs to work with them? And you need to ask the RIGHT people. We all love to make assumptions etc but I promise you, you're not always right 😉. In this case it's the people doing that finance work, and this will at least give us an understanding of what they need before designing a solution. I know, what a crazy new idea, actually asking people things...

BUT this will give you much better direction because from asking this question and a few extra probing ones you might figure out that what they actually need is different from "just create private projects". They might need to work alongside other teams, with only certain projects kept private. Or they might be happy working entirely separately, in which case giving them their own workspace could be enough!

We agree the person on our team who looks after that customer will find out which work needs to be private and which colleagues need access, then bring that back to our next planning meeting. Now we've got something to discuss when we decide what goes into the following release, rather than the same feature request with another week of "we need more details on this".

Coming back to it doesn't mean agreeing to build it

Well, we might get those answers back and still decide we're not building private projects. That's fine! We agreed to find out what they need, not give the request a guaranteed spot in the next release.

Say the finance team tells us they don't actually work on projects with anyone else in the company. Well, if our tool already lets teams have their own workspace, that might do the job! We'd need to check it keeps their work private of course, but we could end up using something we've already got rather than building a whole feature that wasn't really needed. And of course it's super useful to find out before spending a whole week building something!

Or they might tell us they do need to work with other teams, and a separate workspace would just make that harder. Okay, now we know why that suggestion won't help. We can take the actual work they need to do into planning, instead of arguing about whether a private-projects button sounds useful.

And there's still no problem leaving it out of your releases and roadmap. Maybe right now just isn't a great time and we're only building for small teams, and making the tool work across a whole company is more than we want to take on.

But make sure you keep that reason with the request. Because when you later start talking about supporting bigger companies, that's exactly the sort of thing we need to bring back into that conversation.

Otherwise we'll be sitting in another meeting having the same discussion, trying to remember why we said no last time. Was there a reason? Or did we just run out of room in the release?

What to take into your next planning meeting

Here's what I'd want to find when I opened that request again, rather than just "private projects" and a date from three months ago:

• Find out: Which finance projects need to be private, and who outside the finance team needs to work on them?
• Who will find out: The person on our team who looks after that customer. They'll speak to the finance team and write down what they need to do together.
• Bring it back: At the next planning meeting, while we're choosing work for the following release.

With an actual person's name against that conversation, and their agreement to have it, I can come back and ask what they found out. If we've since decided we're sticking with small teams, that decision needs to be there too. Otherwise I'm going to read this and assume we're still investigating, and guess what? ANOTHER round of everything has to start again, learning what and why.

So when you've had that conversation and made a decision, add what you found out, what you've decided and what would make you look again. Keep it with the request, where the next person picking it up can use it without having to track down everyone who was in the meeting.