Who Prioritizes Agile Stories. Ops, Security, Devs or the Business?

The problem is an old one; who decides what a development team should focus on next. Traditionally, we say "the business" but we know that product quality and technical debt can loose out. When does "the business" consider security important? Unfortunately, in todays tech world, security is consistently an afterthought.

I believe I have a solution, which stems from trying to understand the question. "Who decides the priority of a story" is the wrong question. It obviously depends on the story. Agile teams profess working together for a common goal, all skills sharing ideas, planning and implementing together, but we never said that everyone on the team knows everything or is skilled or knowledgable enough to make all decisions. Hence the team thing.

So the answer is "Allow prioritization within skill scope" or said more verbosely, "People with specific skill sets make prioritization decisions related to the scope of their skills and goals".

At the end of the day, everyone in the company wants the same thing. Lets make some money, using quality products that are stable and support the services the business sells all the time, and no one wants our products to be exposed to attack.

Story priorities must be defined in this sequence:

1) Production Operations Team

At the top of the list are stories written by the Production Operations Team. These people know how the products they watch over run and are solely responsible for the day to day stability of these products.

Since all businesses want to maintain the services they are selling, it makes sense that a story addressing a problem in this scope must be prioritized first.

An example might be, the automation of a task that results in errors when performed manually. The removal of pageable errors from log files that have no corrective action. A product deployment process that minimizes over night work.

The impact of a problem that this team faces must be reviewed by everyone, but as soon as it impacts this teams ability to operate the products, then they get first dibs at priority list.

2) Security

Next on the list, a security team is responsible for the monitoring, response to attacks and verification that the development teams are building secure products. Any action that detracts from these goals must be prioritized above anything else since it is core to the businesses desire to protect their customers.

A Security Team is responsible for evaluating risk/reward against all possible attacks, but once a protection is deemed needed it gets into the next sprint, right behind any outstanding Production Operations stories.

An example might be, add validation to a field to prevent an injection attack. Integrate a static analysis tool into the CI build to invest in continuous verification of code.

3) Development Team

A development team is responsible for the building and delivering of quality products to production. They are responsible for ensuring they can perform their duties fast and efficiently and with zero defects.

To address this responsibility the Development Team must write stories that address items that might jeopardize their success. It is within their rights to define how they can best achieve the goals of the team.

An example might be, remove duplicate code to eliminate potential bugs. Implement a test framework that will ensure the code always works. Re-write a legacy code module that continues to introduce bugs to the product and slows down feature delivery.

The Development Team also wants to deliver quality features as fast as possible so is responsible about how they asses the risk/reward of changes.


4) The Business

Does it seem strange that the lowest priority group to set priorities is The Business? This was a revelation to me. I thought of it in a tribe retrospective a few weeks ago, when someone asked  a simple question, "Why did we let ourselves create this problem"?

The phrase "The Business" is mis-used of coarse. A company has many departments performing functions that sustain happy customers. IT is one of those departments and is therefore also "The Business". The mixture of skill sets hired by a company including, accounting, purchasing, HR, and programmers, all allow the business to achieve its goals and make money.

So, lets state it this way, if a department in the business needs some changes in a product, then various skills will be involved to achieve that; IT, support organizations, BI groups, operations teams, sales and marketing, training and the list goes on. To make a change to an established product, lots of stuff has to happen and all those teams are responsible for performing their duties to best achieve the companies goals.

Planning that change and prioritizing it against all the other changes from all the departments is part of the business benefit evaluation that occurs to produce road maps.

In the end, that change, written out as a set of stories, optimized for MVP, and evaluated by the development teams to maintain the road map, gets slotted in to the list of stories that the team must work on.

Fear

I hear you say this is crazy. The business pays me and can fire me? What if the developers decide to take 6 months to make the code pretty, you know how much they want to get rid of all those tabs and it takes them so long to get anything done as it is?

Trust between groups is always a challenge. Different people with different skills and different goals will never completely understand each other so mis-trust is easy. However, people are a companies most powerful asset, so fix that first, and allow them to thrive together.

Conclusion

The most efficient way to move forward is to optimize how each team works. Let the developers prove they can deliver features fast. Let security make our customers safe by allowing them to drive how these products should protect them. Let operations teams sleep well because they know how to optimize their work. With these goals, all "Business" changes will be delivered fast and without question.