(A follow-up to Part I: Why Agile?)
Agile Philosophy
The guiding principles of any Agile methodology are to focus on a small sprint’s worth of work at a time, to engage team members early, and to communicate frequently. In practical terms, this means producing artifacts rapidly so that feedback can be collected, details can be refined, and schedules can be adjusted as needed.
The process of artifact refinement occurs via team planning sessions, with the goal being to produce ever more tightly scoped documents that contain “just enough” detail. These frequent collaboration exercises seek to avoid the common pitfall of having individual team members over-engineer complex problems in isolation. As with any specification process, an Agile team must iterate on artifact refinement until a mutually agreed upon point of clarity is reached. The major benefit of Agile, however, is that by engaging the whole team early during the refinement process, the overall design literacy is increased, and decision points can typically be reached more quickly.
Agile Development
In Agile software development we use User Stories to capture the “who”, “what”, and “why” of a given feature. The “how” is not fleshed out until a given User Story has gone through several iterations of decomposition and prioritization by the team. This approach is designed to save time during a project’s planning stages by keeping the team members focused on users’ needs and forcing them to justify and rank new features in terms of business value. Only when a User Story reaches maturity should tasks be created and packaged for development.
Agile UX
This Agile software development process is facilitated quite well by several popular software solutions ( as I mentioned in Part I, we use Rally ), but when designing end-user software there is still a big piece of the puzzle missing: In addition to capturing a hierarchy of user stories, tasks, and acceptance criteria, we also need a way to construct the architecture and interaction models that will define the user’s experience (UX), and in turn much of the actual implementation.
Using a tool like ProtoShare, we can apply the same Agile principles that we apply to our development process to a parallel UX specification process. This “Agile UX” process should aim for providing project stakeholders with models that find the right balance between scope, details, and fidelity. Additionally, just as with User Stories in Agile software development, an emphasis should be placed on rapid refinement, feedback, and collaboration.
In its early stages a UX prototype should serve as a vehicle for collaboration. As feedback is collected and ideas are evolved, specific interactions should begin to take shape. Once a prototype reaches maturity there should be a clear confirmation of the user stories it encompasses. When it has been approved by the team, the structure and interactions modeled within it will serve as the specification from which Agile development tasks can be generated.
In Practice
Our team at Site9 has found that ProtoShare works very effectively in this scenario. Using the built-in visual discussion tools allows us to quickly evolve an idea with the entire team engaged. Using states, we can model interactions in a lightweight fashion and link them to specific discussion topics for further refinement. The ability to store several distinct Design variations for a single “location” within an interface architecture provides us with an easy way to experiment and evolve ideas, without any fear of losing decisions made along the way.
Once we have evolved a prototype to a point where the entire team is satisfied, we can then link it back to a User Story in our Agile management system. We can create tasks to implement specific UI elements and we can even create acceptance tests that reference specific interaction states within an individual wireframe. This is easy to do because ProtoShare’s review URLs support full bookmarking and are state specific. This means that you can copy the URL of any page, design, annotation or discussion topic in review and link directly to it from within any application that supports hyperlinks.
Guidelines
Having these two agile processes running simultaneously presents its own management challenges, so it is good to have some guidelines going in. First off, it is important that everyone on your team understands that UX design is an explicit part of your overall development process, and a pre-requisite for most implementations. It is also important to realize that a key aspect of Agile is that refinement and iteration can occur at any time, as needed, and will require complete team participation to succeed. Being flexible and adjusting quickly is standard protocol.
While there are no rules that dictate when you should do things, we have found it helpful to have some overlap between our UX and development sprints. This ensures that our engineers always have something actionable in their task pipeline, and our UX team is not going too far downfield without understanding the engineering implications of a given design.
Additional Benefits
We have also found that engaging in collaborative prototyping sessions as a precursor to creating development artifacts can help to clarify, and even discover, additional user needs. Engaging in these brainstorming style prototyping sessions can often result in fewer/quicker development iterations and an accelerated consensus among the team.
Lastly, we often use ProtoShare’s “Live View” capability to collaboratively discuss a production website or application. Whether we are refactoring a legacy implementation, or providing quick post-sprint feedback, it has proven highly valuable to have a single place where we can discuss and catalog the evolution of an implementation over time. Team members can discuss problems with an implementation and experiment with new ideas side-by-side, without losing the context of the current production UX.
Thanks for a nice article, Ben. I oftenhear requests from team members to explicitly tie a user story to a design feature. Of course sometimes this is impossible due to the nature of the story or the feature design. But it’s a request I’d like to be able to deliver whenever possible.
How are you using Rally and Protoshare together to make these associations clear and obvious to your team (we’re currently using a couple of different product management apps, but have not yet standardized on one for our institution)? I can think of many approaches – page documentation, annotations, discussion pins, the Notes area of the element Info pane, etc. – but I’m curious how you might address this by sharing some of your own techniques .
Hi Chris, I’m glad you liked it!
Currently we are relying primarily on using ProtoShare’s stateful Review URLs to link a Rally User Story to one or more ProtoShare wireframes. Rally’s built-in rich text editor allows us to embed a Review hyperlink directly within the description field of a User Story. For a highly decomposed story this often means just embedding a single hyperlink to a specific ProtoShare Design state. When dealing with more abstract stories however, we often include multiple links that may demonstrate a sequence of states within a Design, highlight specific annotations, or even illustrate competing ideas across multiple Designs or Pages.
This approach is very flexible, and relatively easy to follow when using Rally as the “front-end”, however we also recognize the need to reference Rally artifacts directly from within ProtoShare. Unfortunately, Rally does not offer an easy mechanism to reference individual artifacts by URL, so we are currently limited to typing in the IDs of Rally artifacts within the contents of any relevant ProtoShare objects ( Topic, Annotation, Component Notes, Documentation etc ).
Internally we tend to use this cross-referencing the most when using ProtoShare’s discussion functionality. For example, it is often the case that when discussing a new UX concept we will want to continually refer back to the underlying user needs. An evolving discussion within ProtoShare also quite often leads to a refactoring of one or more User Stories in Rally.
Some of our customers have also expressed a desire to link an external requirement directly to single Annotation in ProtoShare, however after some experimentation, I’m not convinced that such a mapping would be flexible enough. We use Annotations to highlight or clarify specific functional aspects of a wireframe, but they are not nearly as formal or rigid as the acceptance criteria that we eventually define for a Rally User Story. Expanding the Component Specification for this purpose is also a possibility, but that too seems like a difficult mapping when considering the relatively volatile and imprecise nature of a prototype’s components.
Ultimately, I think I would find it most valuable if ProtoShare had the capability to link multiple external artifacts to a Design and display their contents alongside the internal Discussion, Annotations, or Page Documentation. The ability to independently link externally referenced items to one or more Design states would also be hugely helpful. What do you think? How do you imagine your development artifacts would work best within ProtoShare?
Pingback: Making Meetings Productive | ProtoShare Blog
Thanks for a nice article, Ben. I often hear requests from team members to explicitly tie a user story to a design feature. Of course sometimes this is impossible due to the nature of the story or the feature design. But it’s a request I’d like to be able to deliver whenever possible.How are you using Rally and Protoshare together to make these associations clear and obvious to your team (we’re currently using a couple of different product management apps, but have not yet standardized on one for our institution)? I can think of many approaches page documentation, annotations, discussion pins, the Notes area of the element Info pane, etc. but I’m curious how you might address this by sharing some of your own techniques .
Hi Sergio,
As you pointed out, there are many possible ways to associate a User Story with a specific design feature. At the moment, our development team finds it helpful to always treat our product management system ( e.g. Rally ) as the “entry point” for accessing ProtoShare designs. Thus the associations or “links” between a development artifact and a design artifact are always uni-directional. We have considered adding the ability to overlay development artifacts on top of ProtoShare designs, but as you noted, the right mapping can be very difficult to determine. While some customers have tried to use Annotations as a type of light-weight user story, I tend to advise against this approach because it becomes difficult to maintain, and is really pushing Annotations beyond their intended purpose.
With that said, when it comes time to associate a development artifact with a ProtoShare design, the first thing to consider is the granularity of the desired association. Typically, we start with “epic” or abstract User Stories in our product backlog. We go through several iterations of visual brainstorming, discussion, and design refinement before decomposing a story into smaller stories or creating development tasks. During this initial phase, any design associations are very large-grained. For example, we often will have several drastically different design ideas. Each competing idea is contained on its own named Design under a ProtoShare Page. In this case it is often useful to include separate links to each ProtoShare Design within the epic Story. Fine-grained discussions and iterations can happen rapidly within ProtoShare, while the product management system simply provides a way to access all of the design artifacts from a single development context.
Once our team has iterated and agreed upon an overall design strategy, we will decompose an epic Story into more fine-grained child stories. At this point, depending on the granularity of the child story, it may be useful to link the child to a specific set of Topics or Annotations. We tend to use these links when the story granularity is such that it represents only a small subset of interaction states on a design. ProtoShare’s stateful Topic and Annotation linking provide a great mechanism for calling out or discussing a specific design aspect, while still keeping the overall design context present. This pattern of fine-grained associations can be extended down through the more granular development artifacts, such as Defects, Tasks, and Test Cases. Whether or not this will be helpful depends largely on your process and the size and distribution of your team(s).
NOTE: To create a stateful link, use the same “Link” button on the top right of the design viewer toolbar. The link will automatically link to the selected Topic or Annotation, and include the active Design state.