Agile User Stories and Application as Persona


In Agile, requirements are communicated via user stories.  Traditional user stories use the form, “As a …, I want to …, so that I can ….”.  For example, “As a first time user, I want to be able to create a user name and password, so I can securely do transactions.”   That enables functional requirements to be captured as user features, but still does not address the often critical “non functional requirements” (NFR) in an Agile framework.  NFR are items sometimes associated with infrastructure, such as capacity, scalability, reliability, availability, or security.

One approach to including NFR in an Agile context is to create user stories based upon the application itself as having a role or persona.  For example:

“As an application, I want to be able to process xxx transactions per second, to be able to handle peak monthly demand.”

“As an application, I want to be resistant to SQL injection attacks, so that my transaction integrity remains valid.”

Appropriate acceptance criteria need to be included; phrasing those can be challenging in these cases.

Extending the concept of the application persona further, it can also be used for other aspects of the application, such as user interface or user experience.  Those may fall outside the straightforward transactional features covered by more typical user stories; use it for the more qualitative ones, the fuzzier parts.  The usual guidelines still apply: make the story as granular as possible;  and to include acceptance criteria.  Acceptance criteria can be very difficult to create when one is trying to specify aspects of user experience as quality or beauty.

Taking this further still to the more general case of product development, including the difficult cases of ad campaigns or branding, the concept of the application or product as a persona remains tenable.

E.g., “As a brand, I want to be able to highlight the excitement of using our products, so that I can …..”

Advertisements

Choice is a Gift

 In traditional development methodology, tasks are assigned to the developer, usually by their manager or by the project manager.  In an Agile environment, the team is self-organizing.  Managers accustomed to hierarchical or command and control cultures find this unsettling, almost heretical. But repeated studies (e.g., Forrester) have shown Agile teams to be more productive.  Within the Agile community, one even discusses a team becoming hyper-productive, as though achieving an elevated state of awareness, transcendent.

 My assertion is that giving the developers the ability to choose is a major contributing factor in that increased productivity; furthermore, that this can be applied in non-Agile environments.

 It is not just the selection among different options that is empowering, but the detailed involvement in the decision process.  With that involvement comes a commitment of mental energy, an increased degree of being invested in the outcome.  The ability to choose is by itself a reward. 

 Effective choosing cannot be done in a vacuum.  As a manager, part of your role in giving a team the ability to choose is to make sure that they have correct information, as rich a context as possible for their decision;  where this fits within a larger view.  Your ability to communicate your vision is an essential ingredient in the outcome. 

 One must factor in the nature of the team:  how experienced they are; their knowledge of both subject and technology; their interaction with each other.  The degree of guidance you provide is part of your art as a manager. 

 Trust is key: bi-directional trust. You trust them, but they also need to feel that you have their back covered. Do you trust them enough so that YOU take responsibility for their choice?  If your boss comes asking, it’s still your responsibility.

 Choice can also inspire creativity, options as a gateway to innovation.  You believed the options were A, B or C, but once the team got actively involved in the decision process, they came up with a supersonic rainbow that did it faster, more reliably, and made the users happier.

 As a manager, it takes courage to trust your people and give them the gift of choice.  Reward them with this, do it wisely and well, and don’t be surprised if their excellence exceeds your expectations.