On many occasions I am asked the question “How do we incorporate architecture needs into Scrum?”. A few years ago when I first started tackling this question on projects my answer was just put them on the Product Backlog. Over time I found this approach had issues in certain circumstances. Here are a few examples:

• Product Owner would not prioritize architecture focused Product Backlog items
• Value was difficult to communicate without heavy documentation for Product Owner or one of their trusted advisors in architecture
• Product Owner did not understand results of architecture implementation
• Some architecture focused Product Backlog items were too large to fit into a Sprint
• Many architecture focused Product Backlog items showed up right before they were “needed” and therefore decreased predictability of releases

At Agile 2006 I was at a talk given by Mike Cohn on User Stories. A question came from the audience regarding security concerns in User Stories and Mike had an interesting response. He brought up the notion of an abuser perspective User Story. I do not remember his exact example but it had to do with a Hacker trying to take down your web site. Almost immediately this was a revelation to me. My familiarity with Bill Wake’s INVEST in Stories article enabled me to link the INVEST model, architecture needs, and abuser perspective User Stories. Here is an example:

As a Malicious Hacker I want to ciphon credit card information so that I can use it for fraudulant purchases

This user story has added the user role of Malicious Hacker and their criminal intentions for our system. If I were on a project that had features which revolved around credit card information I may not have enough time to delivery user interface functionality along with implementing a third-party software solution or configuring our systems to handle these situations effectively. This User Story would allow our team to focus on implementing architectural elements stopping a Malicious Hacker from ciphoning credit card information out of our systems. Also, this User Story meets the INVEST model in the following ways:

• Independent - a team could implement, in any order, this story or any other story involving user interface functionality with credit card information
• Negotiable - the Product Owner could negotiate with the team on the best approach to take based on business and technical suggestions
• Valuable - a Product Owner can see this as valuable since it would be highly costly to allow a Malicious Hacker access to sensitive data such as credit card information
• Estimatable - based on the negotiation between the team and Product Owner, a solution could be estimated by the team focused on specific acceptance criteria
• Small - the solution would only involve security of the credit card information rather than a generic security solution
• Testable - multiple security cracking techniques could be attempted and foiled by the implementation of this user story

This User Story can now be prioritized by the Product Owner. Once it is high enough in priority we can take the User Story card and have a conversation about it and drive out the essential confirmation or acceptance criteria for this User Story as described by Ron Jeffries.

In conclusion, think about how you can use the abuser perspective to help describe User Stories that meet the INVEST model for architectural needs. Helping the Product Owner understand why architectural elements are valuable through a narrative approach such as User Stories will enhance trust between the team and Product Owner. I have also found that the process of deriving User Stories in this manner helps the team solidify their technical suggestions into smaller components which are more easily managed in an iterative and incremental approach such as in Scrum and Extreme Programming.

For reference, creating user roles from an abuser perspective was added to Mike Cohn’s SD West 2007 presentation on User Stories.

Be Sociable, Share!

• 
•