How to build a feature backlog bottom up

Question

Does anyone have any experience with bottom up product management? Essentially getting their teams to decide on the features and the direction of product?

In most of my previous teams - product management and stakeholders would decide on features and themes and I would then get my teams to write user stories and tasks to deliver upon this roadmap.

However with my current team we are fortunate to have been given more control. We still have constraints but we have been allowed to do bottom up product management essentially. The organisation has decided a high level direction for the year but we must decide which features are needed.

Does anyone have any good methods for getting scrum teams to do this?

My initial idea was just to have a team funnel where all individuals would submit ideas captured on a wiki or something and signify the complexity and impact of their submissions. However the idea is a bit meh and I kind of want the feature backlog in a month or two so perhaps a workshop is needed.

Answer 1

You might consider using a technique like story mapping.

It would also be worth having a conversation with the team about how they define value. With a clearer idea of that you will be better placed to prioritise the backlog.

Answer 2

I think Scrum does exactly what you want. The team as a whole add items onto the backlog (backlog refinement) and the Product Owner is the person on the team who sets the priorities.

If you don't yet have clear product ownership then you need to work out how accountability and controls will be exercised and, most importantly, how business value will be measured. Having those annual goals is a start but is very unlikely to be sufficient because of the inherent riskiness of such long term goals. To be successful the team will need to deliver results with every iteration, get stakeholder feedback and then adapt their approach based on that feedback. The role of the PO is to make that happen and so optimise the value of the work the team delivers.

Answer 3

As mentioned in other answers, you can go for story mapping exercise but first you may consider aligning all stakeholders to a prioritisation framework and high level objectives/ themes/ Epics (for the product you are building).

The main problem with the bottom-up approach is the divergence of ideas from different individuals which may or may not be aligned to the objectives/problems at hand. If participants know the key challenges they need to solve for and also a general sense of how their items are going to be prioritised compared to other ideas, the backlog would be more refined from the get-go.

Answer 4

A really fun way is doing a Design Sprint. Followed by some Impact mapping and User story mapping.

Depending on your product get out of the freaking building and let the developers talk to actual users. Maybe research the Shiftup program to help you facilitate continuous innovation.

Bring the team together with the users and key-stakeholders, get and keep the conversation and feedback-loops going and discover the features TOGETHER!

Answer 5

I can also really recommend the User Story Mapping technique.With it you can align your team in one direction and all team members can plan the project. If everyone is involved in the planning process, the ownership is much higher.

Answer 6

I often see teams using both a top-down and a bottom-up approach at the same time. But, then again, maybe I'm using the term "bottom-up" in a slightly different way.

"User stories," to me, are top-down: "this building is going to have a magnificent stone archway over the front entrance."

But someone's also at the same time working bottom-up, figuring out how to actually implement these things in the greater context of the whole. "In order to do this, on day #41 we're going to need to have in place a temporary support structure capable of holding up 2,300 pounds. Which must be designed like so. Therefore, by day #36 the foundations must be in place, and tested to be sure they'll hold the weight."

The teams divide themselves to be looking at both ends at the same time to be sure that they meet in the middle.