Make a dashboard, split it by size and security risk, and let your team place stories in the right areas of the dashboard. It takes at most five minutes and you can estimate without boredom.

Estimates are always wrong. People feel uncomfortable in defining a time for their tasks because often others will take that as a schedule. The Agile movement came up with attempts to make this activity enjoyable and insightful (think of Planning Poker or T-shirt sizing). Most of what I read tackled how to quantify the effort needed for a story.

Now, effort is not the only thing worth estimating. As I mentioned in my post "Linux, Unix Philosophy and why programs are just filters", people are data creators. Sometimes this data is confidential. When you offer a service to other people, they will create data and you will have to deal with that assuming that need to stay confidential. Assuming our existing service handles data securely, we would like to avoid to make it insecure when we extend it. So, security risk is something engineers need to be aware of and ideally estimate.

Estimating security is difficult. There are several approaches and they always require checklists and lengthy data flow modelling. I believe some of these practices happen too infrequently and, if not, they are prone to become boring ceremonies. I believe that security (and also monitoring, but lets leave this out for now) should be part of story planning. It is also disturbing that engineers do not have a taste for security issues: if not us, who else could protect users' confidentiality?

Recently I had the privilege of collaborating with the smart people of QWAN, and they suggested a simple way to take away the boredom of estimating effort: just make a dashboard, split it by story size (similar to T-shirt sizing: Small, Large, Extra Large), and let everybody in the team place stories in the right area. If somebody strongly believe that a story is of a different size, they will point it out and the team can debate about it. Shortly this became our default approach to estimate stories.

After seeing how effective and efficient this simple method was, I thought: "What about approaching security the same way?". Here my proposal: let's make our dashboard a matrix where we also have a risk size.

This is a sample dashboard I am thinking of:

Story size (or complexity) stands for how difficult is to implement a feature. Security stands for how likely this will break confidentiality.

I also like that teams customize the dashboard a little, this is what I would do for making it more familiar to me (I think it also increases efficiency in recognizing where to place things):

What I propose is that given a backlog of stories, the team members will concurrently move them in the right areas. For example:

In the example above, the team estimated that changing static text is simple and has no effect on user's security. Instead they estimated that opening an internal API to the public is of average complexity, but it risks to expose users' confidential data.

Important note: the point of this method is the debate within the team. The main benefit of any effort estimation is to refine our understanding of the effort itself (think of "grokking the effort" if you enjoyed the sci-fi book "Stranger in a Strange Land"). Also in this case, the main benefit of estimating security is the generated debate about security topics: imagine a team member positioning the "opening API to public" into the "Safe" area; now another colleague will move that story into the "Horror" area; ideally the first will ask the latter why and this will trigger knowledge sharing about security risks and concerns.

I propose that this approach can make visible the security concerns of user stories.

I envision that a business could use security estimates to roughly calculate the risk a company is taking at every iteration, and take decisions accordingly. Although this is just a wild guess because these estimates are subjective to the team, and so likely unreliable (but all estimates are like that).

So the steps are easy, make a dashboard, split it by size and risk, take your backlog of stories/tasks and ask your team to put it in the right area of your dashboard. We need more security awareness and knowledge sharing and we may make that happen through effective security estimates.

The software I used for making this example board is Miro, which I found quite enjoyable to use and helpful for remote collaboration.