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

Supporting Application Development

Methodologies or frameworks for the infrastructure to support Application Development (AD) is an interesting topic by itself, but one I’ve seldom seen mentioned or described, despite ITIL.  Even in companies that are following ITIL practices, the procedures are not often accompanied by feedback mechanisms to further improve things.

For example, do you trace incident or problem reports back to application change requests?  For major changes to application software, compare the post-implementation defect levels for different application groups.  Investigate the differences and consider ways to improve application development practices.

Many organizations believe that by designating support staff as level 1, 2 or 3, that they’ve established real procedures.  Other than “expected time to resolve” criteria, I’ve seldom heard of any real process analysis associated with those categories.  Nor have I heard of processes for a more organizationally flat structure.  A process needs to be more than assigning a severity level and contacting a software vendor.

What are your company’s infrastructure processes for supporting AD efforts?  What are the feedback mechanisms in those processes, such as periodic reviews?  If you were an infrastructure manager, how would you know how effective has been your support for AD, and where there may be perceived deficiencies?

Does each organization have a clear view of major plans and events for the next 3 to 6 months?  Does the AD area have any clues as to when systems is thinking of upgrading the version of the DBMS, or other essential software?

Hint to infrastructure:  if an AD team is pedal to the metal on delivering to the business, 2-3 weeks notice that you’re planning to upgrade to a new version of some key component is likely to be greeted by less than rabid enthusiasm.

Hint to the AD manager:  if you have not budgeted in time, resources and tooling (test scripts, etc.) for at least one version upgrade per year of the DBMS, and at least once every other year for the OS, some rude surprises may await you.

A tale of non-communication, with details altered out of sympathy:

Application development has a software product from a vendor, with much in-house enhancement.  In their published plans for the next quarter, AD had included an upgrade to a newer version of the product.  They knew that a newer version of the DBMS than currently used by the application would be needed for it, but since that newer version was already in use in-house by other applications, they were not concerned.

When the specific requirements became official requests to the infrastructure, the fun began.  The newer version of the DBMS required a newer version of the operating system than was currently used by that application.  And their servers were only marginal for the newer level of the OS; a hardware refresh was recommended.

The newer version of the OS not only brought along new run-time libraries, but used newer versions of compilers.  Even without any hardware refreshes, the regression testing alone for the DBMS and OS upgrades added significant time to the overall project.

Lesson learned:  frequent regular review of upcoming plans, including details as “DBMS version xxx needed.”  A review, meaning a meeting (even if virtual), with some communication, should be held.  Make sure the right people are talking to each other.

Rejuvenating the Infrastructure

The lack of agility of the infrastructure, especially the data center and systems programming/ administration is so obvious that the nascent DevOps movement has arisen to combat this perceived deficiency.  Much of that movement’s visible contribution has focused on automation and tools (e.g., Chef, Puppet, cfengine, Nagios) rather than on frameworks or processes.  Not surprising, given the talent for coding of many of the DevOps advocates.

There are other obstacles:

The Data Center values stability of the environment, and resists change; change is seen as a risk, not as any form of added value.  In general, perhaps especially for larger IT shops, other than changes due to bug fixes or security patches, the data center is isolated from positive aspects of application and environmental changes.  New metrics could provide a more flexible approach along the lines of increased Business Value (BV).  Some places, especially those along ITIL lines, may use a metric for risk as part of Change Control, but I have not heard of a corresponding one for enhanced BV.  That BV metric could be a 1 to 5 scale, or a set of numeric guidelines.

Much of the effort of the infrastructure is about process, with solutions well defined.  The challenges are more along the lines of:

–       Sheer scope of tasks, as the whole enterprise may be involved, with associated risk of that dimension.

–       Interdependencies

–       Complexity

–       Volume of work (especially with sharp peaks)

–       Lack of teams

For volume, automation and tools can help; one should also investigate frameworks like  Kanban, limiting the work in progress at any moment.

The lack of teams in infrastructure remains a source of concern for me.  Teams, behaving as teams, not just silos of individuals with common product-oriented expertise.  For example, a group of system administrators each with distinct separate sets of servers to manage, with no or little collaboration between members of the group, is not a team. The situation not only deprives the company and the participants of the benefits of a team approach, but reinforces the sense of isolation and endless repetition of upgrades and patches.

In my prior blog post on Skill-Centric Teams, a key point is that teams can be created across functional silos, basing them on the shared skills and challenges.  While there are distinct differences between a UNIX system administrator, the Windows counterpart, and their mainframe brethren, but there is so much in common, including, but not limited to:

–       Issues of change management

–       Communication with developers

–       Application development (AD) support methodologies or frameworks

Application development infrastructure support frameworks deserve a separate post.