Feature Planning and Prioritization


A customer of mine recently asked me for some help in managing the different feature requests. Their current process was to just to work on features requested by the person with the biggest stick or loudest voice :). We have all been there.

Back when I was working with Windows Sustained Engineering, we used to joke about arm-wrestling program managers to get our features bumped up in priority. Needless to say that it didn’t work out so well….constantly context switching between the most “important” feature felt like running in place. It felt like a lot of activity, but nothing really ever got done. Customers were unhappy, we constantly missed deadlines, dev’s burned out, etc.

The entire team noticed that things were getting out of hand, and collectively made a decision that this couldn’t go on much longer. We had a Feature Bar to make sure we worked on high priority items, but it was very easy to manipulate and it wasn’t really being followed. One of the first things we did was revisit our Feature Bar. We educated the entire team on what it meant and how to apply it properly.

We had broken down the bar into multiple areas in that worked for our business model.

  • Microsoft Business Value
  • Customer Impact and Opportunity
  • Development Risk and Complexity
  • Testing Risk and Complexity
  • Workarounds
  • User Applicability

When evaluating the backlog, we would factor each request according to the criteria above, and score them a Low\Medium\High. Each category would add or subtract from the feature’s final score. The final score would help determine a feature’s priority, and we were able to have very reasonable conversations about what to work on. No longer could someone game the system. Also, we could be very transparent with our business partners that we are working on the most high priority work items. This helped prevent escalations to begin with, and gave the developers breathing room to actually work on features and ship them out the door.

The above wasn’t the magic bullet to solve all the problems, but it was the first step to get everyone on the same page. When building an extremely complex and large product as Windows, managing all the different stakeholders and requests was super important. We got feature requests from other teams at MS, OEMs, Partners, Customers, Support Engineering, Marketing, component teams, Dr.Watson reports, etc. Managing the work coming into the team was a major task and defining a common bar was the first step. Applying it consistently was even more important!

(After we got the better at applying the bar, we did eventually move to a more agile concept where we bunched work into sprints and releases rather than working on individual items at a time, more to come on that later.)

 

Also, I wanted to share how another team at MS does feature planning and prioritization. Corey Sanders who is the Director of Program Management for Azure talks about how his team does feature planning and takes input from all their different stakeholders. 

https://channel9.msdn.com/Shows/Tuesdays-With-Corey/Tuesdays-With-Corey-A-little-bit-about-the-Planning-Cycle

Watch the video and watch him rattle off all the people that he collects feedback from and how. The team then takes all the feedback and puts it through their planning process and hands it to the different component owners.

When stuff doesn’t go accordingly to plan, he gets lot of “feedback” on his twitter handle (@CoreySandersWA). Feel free to send him some feedback as well. I worked with Corey back when he was a dev owning the Windows servicing stack and then RDP. I was a young punk hanging outside his office in Bld 28 trying to get my features implemented. He will truly appreciate any constructive feedback that can help make Azure better…..just don’t tell him I sent you. 🙂

 

Listening, Prioritizing, and then getting things done. Its just that simple….atleast in theory….now if only I could get my customers projects teams on board….

-Omer

 

 

 


Comments (0)

Skip to main content