We use a ‘Design the Box’ exercise to help teams cultivate a shared understanding of a product/project vision. The technique comes from Bill Shackelford (Shackelford & Associates). One of the aspects of the exercise asks teams to define the Operating Requirements for the product, and I found early on as an instructor that I was often getting technical constraints listed and not true operating requirements. As a result I’ve modified the way I explain Operating Requirements and use it as an opportunity to describe the difference between the two types of content.
Summary of ‘Design the Box’
For people on an Agile Team, the ‘Design the Box’ exercise is a collaborative technique that allows team members to cultivate a shared understanding of the product’s vision by treating it as a product that would be shrink wrapped and sold on a stores shelf. Unlike product charters, the ‘Design the Box’ exercise engages each team member and is an information radiator that goes on the wall, as opposed to a shelved document that few people read.
Team’s completing the exercise design the front and back of a box that summarizes their product.
|Front of the Box
– Name of the Product
– Key Selling Points
|Back of the Box
– Product Description
– Key Features
– Operating Requirements
So, to provide the distinction necessary, please take the following definitions & examples into account.
- Operating Requirements: Any requirement an end-user must adhere to in order to use the product.
— A certain browser type and/or version
— Amount of space on a hard drive
— A specific mobile operating system or device type
— Amount of processor speed
— Specific operating system (Apple vs PC)
— An internet connection speed
- Technical Constraints: Any architecture decisions that are made that may impact the design of the solution.
— A certain programming language (.NET, Java, Cobol)
— A certain database type (DB2, MySQL, Microsoft SQL Server)
— Certain compatibility requirements, based on legacy systems perhaps
It is important to distinguish between the Operating Requirement & the Technical constraints. The clearer the technical constraints, the less likely the product will be to fail when it comes time to implement. The leaner the Operating Requirements, the less boundaries exist to an end-user adopting the product and the more clearly understood and defined they are the less likely for a poor customer experience because of customers attempting to use the product and running into frustration because they do not meet requirements for operating it.