Story Lenses

Emanuil Slavov

Aug 14, 2015 • 3 min read

In parts of my life, where I don’t deal software, I’m creating games in the real world. One book that I find particularly useful for game design is The Art of Game Design: A book of lenses.

![The Art of Game Design](/content/images/2015/08/the_art_of_game_design.jpg)

The book forces you to think about different aspects of your game — is it fun, is it challenging, is it rewarding, it is balanced, puzzles difficulty, what skills are needed, what is the flow, what’s the goal, how the ranking works and so on. These are the lenses. They make you see your creation through different set of eyes. You can think of them also as a checklist not to miss anything important. If you want to dig more into this topic, read The [Checklist Manifesto: How to Get Things Right](http://www.amazon.com/The-Checklist-Manifesto-Things-Right/dp/0312430000). Also, apparently Apple is using an extended checklist [when launching products](http://qz.com/183861/any-company-can-copy-the-keystone-of-apples-design-process/).

So what does this have to do with software development? Quite a lot. You’re probably aware of the fact that the early we catch a problem, the easy and cheap it is to fix it. It’s best when we find a problem even before a single line of code is written. So the ideal place to brainstorm potential problems is when a story is first introduced to the team.

From years of experience here is a compiled list of story lenses to look your story through:

Architecture

Any frontend changes required?
Any backend changes required?
Any database changes required (schema or data, new collections)?
Will any brand new service, module or package be created? Are we only modifying the existing ones?
How the change fits into the current architecture? Is our current infrastructure adequate to accommodate this feature? Do we need to rethink out current infrastructure because of this new feature?

Testing

What type of manual testing is needed? All prerequisites ready — environment setup, accounts, training?
What type of automation tests will be written? Unit, Integration, API, UI. Who is going to write them? Sync between people writing the tests so that there are no gaps and work repetition.
Does the team have the technical knowledge to write the automated tests?
If testing an external service, will a stub, mock or simulator needs to be written for automated API/UI and performing manual tests?
Do we need to setup any test data or database?
Do we need to create any new CI job? Any changes in the current continuous deployment pipeline?
Do we need to add any additional static analysis checks?

Deployment

How is this feature going to be deployed? Do we need changes to deployment scripts (packaging, firewall rules, database schema changes)?
Any changed to the current working environment needed (network, OS)?
Is any new hardware needed or upgrade of the existing — memory, CPU, storage, bandwidth?
Any new servers needed?

Operation

What information will be logged? Where?
How is the feature going to be monitored?
How is this feature going to be debugged if needed in production?
Are there any flags to enable/disable this feature in production?
Given the resources we have today, will this feature be able to function the same way a year from now?
A pre-mortem by the team. We release this feature and it’s a spectacular failure. What could be the reasons?

Dependencies

Are there any 3rd party dependencies outside of our control — libraries, packages, services?
Do we have the necessary contracts, licenses, accounts, login information?
Any due payments for such a dependency - one time, monthly?
Anything document that need to be reviewed by the legal or finance department?

Performance

Do we expect any increase in memory consumption?
Do we expect increase of CPU load?
Do we expect increase of i/o disk operations?
Do we expect more calls to external services?
Do we expect more database operations?
Do we need to do performance/load/stress testing of this feature before release?

Security

Any potential injection vulnerabilities - XSS, SQL, code, OS commands?
Any potential business logic vulnerabilities — e.g. viewing information not intended for current user, privilege escalation.
Any automated security scanners need to be run (both external and as static code analysis)
Any user privacy considerations?

Usability

Does this feature needs to be reviewed by UX person?
Will this feature need to be internationalized or localized?
Does this feature require extra effort for accessibility reasons?

This is best done when the whole team that will implement the feature is in the same room, on your planning session for example. Some of the lenses have the potential to completely change team estimates, but that’s OK. It means less unpleasant surprises later, less rework and less bugs.

Speaking form my perspective, I may have missed some lenses. I’d like to read about your unique perspective. Something missing? Drop me a line to discuss it in the comments section bellow.