Technical Sushi Burrito Brief

I always get hungry when staring at that header image. It’s undeniable how much I like sushi burritos. However, after reading this post, some of you might come up with your own name for this estimation technique. My colleagues call it poke bowl brief or burrito brief; I am good with either. Let me know in the comments below how you would name it.

The idea of a Technical Sushi Burrito Brief is to define and estimate the cost of each item in a sushi burrito as if it was an add-on. First, we need to calculate the cost of the base ingredients, such as seaweed wrapped in rice, some veggies, and salmon or tofu (vegan or non-vegan options, respectively). Then, we need to estimate the cost of the additional items, such as guacamole, sour cream, tuna, crab, and extra protein. Done! We have a Sushi Burrito Brief.

At this point, that analogy might not make much sense. So, let’s take an example. The screenshot below illustrates the designs for a new feature to allow users to highlight text in case law decisions. The designers made sure to cover all user requirements, and, among other functionalities, we can see three main areas, A, B, and C. The first area, indicated by the letter A, is pretty much the text highlighting itself, while area B would allow users to easily navigate through different types of highlights, and area C would be a button that opens a menu to allow users to easily hide or delete all highlights with a single click of a button. Awesome! that’s what all users wanted during the user exploration and user testing.

So, now that the designs are done, they are handed off to the engineering team to estimate its implementation cost. It turns out it is a quite complex feature; it would take a small team a full quarter to develop it. Consequently, this project was left aside, and it would have probably been sitting there for some quarters if not years.

However, given that it is a highly requested feature, what if the stakeholders were not provided with a single estimate, but a range of estimates, where they can pick and choose the add-ons as if they were building their own sushi burrito?

The matrix below exemplifies the overview section of a Technical Sushi Burrito Brief, detailing the best and worst-case estimates for the base text highlighting feature (frontend, backend, and metrics) and its add-ons. Rows highlighted in green were picked by the stakeholders to be implemented, while the remaining add-ons were left behind for the second iteration of that feature.

Besides the estimates matrix, a Technical Sushi Burrito Brief contains other details usually present in any Technical Brief, such as flow diagrams, systems designs, data models, functional and non-functional requirements. Each Tech Brief is then reviewed by at least another engineer to make sure the estimates make sense.

You can also argue that the designs should not be that complex in the first place, but that’s a topic for another blog post; let’s just assume the designs represent an excellent text highlighting feature. In my next post, I will share how was the implementation of this feature and how we were tracking engagement to determine if it is worth it or not to implement the remaining add-ons.

I hope you liked this article! Have a great day!