English | EN 
The Product Risk Analysis (or PRA in short) is often associated with old school waterfall development practices and as such deemed non-Agile. I think that is a misconception. True, I’ve witnessed PRA sessions with an overload of participants that took ages to complete. Conducted this way the PRA does not fit the Agile way of work, but to be honest, they didn’t really fit Waterfall either, it was just bad practice, no matter how you look at it!
In Agile too, testing is still a risk based practice. We know we won’t be able to test everything, so we need to prioritize and make choices on where and how to spend our precious time and resources. A lean and mean version of a PRA is called for and with the help of SF DePOT, I think we can do just that.
So what is SF DePOT? Some storage facility or station house in San Francisco? No, nothing of the kind. In fact, it has nothing to do with San Francisco other than being a mnemonic for the first two letter of the acronym used to easily memorize the concept. Likewise, DePOT is there because it sounds okay.
SF DePOT is an acronym for Structure, Functionality, Data, Platform, Operation and Time (the small ‘e’ is just there to pronounce it smoothly ;-). The SFDPO part was originally coined by James Bach in this blog post, the T came in later.
It acts as memory aid during the PRA, helping to assess a product from different angles, preventing us from focusing too much on Functionality only. Traditionally, more extensive models of quality attributes were used in PRA’s – e.g. ISO 9126, later replaced by the even more complete ISO 25010 – to verify completeness.
Let’s briefly go over the individual letters:
S for Structure: What is the product made of? What files, libraries, etc. Can I test it module by module?
F for Functions: What is the solution meant to do? Can we access it through a GUI, an API or both?
D for Data: What are the input and outputs? Are there intermediary data sets? Are there constraints or default values?
P for Platform: What platforms does the solution run on? Any specific versions? Is it depending on 3rd party controls/libraries or open source software?
O for Operations: Who uses it and how do roles relate to permissions? How do different users use it?
T for Time: are there any time related constraints, time sensitive orchestration, leap years? Does first time use differ from subsequent ones?
The result of an SF DePOT session are sets of associated risks. This can be sets that map perfectly on the 6 letters of the acronym itself, but we can decide to split it up in more detailed characteristics (e.g. Usability pulled out of Functions) or add topics such as performance or security from the start. It’s meant to help you, not to restrict you!
The nice thing about SF DePOT is its compactness, its easily introduced, easily memorized and easily used by both frequent users and infrequent users. The latter is an important aspect of SF DePOT. The true value of risk based testing lies in identifying and discussing possible risks with a broad variety of stakeholders. SF DePOT is an excellent aid in small Three Amigo risk sessions, but it works just as well in a broader setup that includes e.g. non-frequent business participants or technical specialists.
One piece of advice when organizing a broader session: make sure to start the session with a ‘scope definition’ moment. You’d be amazed how people can think differently about what you are developing! This difference in perspective can be as simple as scoping the session to ‘the MVP only’ or to ‘the full scale solution after x sprints’, but especially when conducting a PRA with stakeholders that only part-time work on the solution (flawed!) assumptions on scope tend to surface. Take some time get those out of the way before you enter the essence of a PRA: identifying risks!
One nice ‘extra’ of SF DePOT sessions is the guidance it provides for test design, especially when the next steps apply Behaviour Driven Development (BDD). The sets of risks form an excellent starting point for decomposition of scenarios.
