Bring UX to Your Agile Process

Agile shops face a unique set of challenges, the largest is not being able to track feedback and decisions prior to coding sprints. Communicate more clearly with stakeholders and track design and UX decisions by incorporating ProtoShare into your existing Agile development process.

Prototype the Backlog

As an Agile shop, your team is already addressing the pitfalls of traditional software development (late-stage changes, involving the customer too late in the process, etc.). Now, you can make your team even more efficient, communicate with stakeholders more clearly, and track all design decisions by incorporating ProtoShare into your existing Agile development process.

Key Benefits to using ProtoShare with Agile:

• Engage your UX team early in order to increase team consensus and discover potential usability issues before a sprint begins.
• Reference a prototype or even specific interactions within a prototype, directly from your user stories, tasks, and test cases.
• Gather real-time feedback from your team and rapidly evolve your UX specifications and user stories in tandem.
• Track and discuss your development team's work-in-progress using Live Views.
• Rapidly prototype and evolve all of your design concepts in a single shared location, increasing stakeholder visibility and reducing re-work.

With Agile, how do you know when you're "done"?

Even the most successful Agile teams can have problems adequately defining what it means to be "done" with a user story. Particularly when building software or websites for consumer consumption, determining whether a feature is ready for release can be a challenge. Various Agile teams define this differently (ready to ship at the end of a sprint, one sprint away from being ready to ship, etc.).

Agile acknowledges the need to continuously build a working system so that stakeholders can be engaged throughout the development process. While this allows course corrections to occur quickly, they are still costly. Increasing the clarity of your requirements up-front is the best way to mitigate the risk of slipped deadlines or even worse, additional iterations. Having completed and adequately tested code doesn't mean that it's releasable.

In the worst-case scenario, the Product Owner and the rest of the team disagree about the meaning of user stories, and this is only discovered at the end of the sprint. More likely, the development uncovers issues or features that are required to be complete before new functionality is actually releasable to the customer.

Now these features can be added to the next sprint, which is good, but the code is not releasable at the end of the current sprint. This situation is caused by a failure to package work items into a sprint that provides adequate quantum of value. Most often, this failure is due to lack of clarity in the user story.

This is where ProtoShare can help. By prototyping stories in the backlog, ambiguities and hidden user stories can be uncovered before a sprint starts. Acceptance tests can be illustrated in the prototype. This allows better agreement with the Product Owner and clarifies the definition of "done". It also gives the Product Owner tools to communicate with other stakeholders about the business value. When you prototype, the result is more clarity in the stories, fewer missing stories, more thorough test cases and wider agreement on business value.