When I was at Tripwire, we did a retrospective and came up with a document that described what worked mechanically — and set a framework for other teams to use to do sprint planning  as we scale “UX” to other projects…

Image

What I’m really doing during stand – up …

The point of writing this was to attempt to address the need to support UX design time when we couldn’t get out in front of the devs by a number of sprints.    This continues to be a giant thorn in my side  as I am struggling to “draw screens” in sprint.  

Development Philosophy
1. Feature definition and UX design are hypotheses that are partially wrong
2. In recognition of that, we expect and plan for rework
3. We do not consider a story done until it has been updated in response to user feedback
4. During the development process we will value iteration over doneness
5. When user stories are merged they will have been fully tested and have all bugs fixed

The Mechanics ( for the SCRUM Masters)
• What we now consider stories will generally be implemented in  our backlog as epics in our agile project management tool — Version One
• The epics will include a first round of wireframes and user testing, to vet concepts and patterns. This could be considered a “sprint zero” for a story
• The stories in the epic need to be able to be finished within a sprint time-frame
• The epic will include both front-end and back-end stories
◦ The front-end story should include stubbing out the eventual back-end in order to get code in front of a user as soon as possible
◦ The front-end story isn’t complete until a round of usability testing and resulting UI updates have taken place
◦ QA against the front-end stories is exceedingly light (or nonexistent) before the first user test
◦ After UI updates, testing against the stories can be done to its usual completeness
◦ Back-end stories will be made as granular as possible, and can be done in parallel with the UI work since the basic concepts have been validated
• The epic will contain a “done is done” story that allows the team to run the whole story through its paces with all of the pieces working together
• We will create a branch per epic and merge the epic when it is complete
An Example
The team is going to implement an epic (theme?): Audrey informs Conrad that she quits. This is how it is represented in our story tracking tool
• (Epic): Audrey informs Conrad that she quits via an email form
◦ (Epic) Audrey fills out an email
▪ (Story 1) Design the form UI and test the concepts
▪ (Task) Create basalmiq wireframes
▪ (Task) Revolving door usability testing
▪ (Task) User feedback
▪ (Task) Refine
▪ (Story 2) Create and test form UI
▪ (Task) Create contract and stub the back-end code
▪ (Task) Write the UI
▪ (Task) Lightweight UI testing
▪ (Task) User feedback
▪ (Story 3) Populate email “To” choices from Audrey’s contact list
▪ (Task) Implement API to retrieve contacts
▪ (Task) Test it
▪ (Story 4) Send the email on form submission
▪ (Task) Implement form submission API
▪ (Task) Test it
▪ (Story 5) Complete Form UI
▪ (Task) Rework form UI per user feedback
▪ (Task) Apply look and feel
▪ (Task) Test it
▪ (Story 6) Done is done
▪ (Task) End-to-end scenario functional testing
▪ (Task) End-to-end scenario usability testing
▪ (Task) Bug and usability fixes
▪ (Task) Performance testing
▪ (Task) …

We will execute stories in parallel as much as possible to accelerate toward completing and merging the epic.

Challenges
• Introducing user test cycles could potentially introduce delays to continuous merging. We need to take care to keep stories small and apply parallel efforts in order to mitigate this.
• Receiving iterative deliveries of “not done” work from development represents a significant change to the way QA works. We will have to have strong communication, especially with offshore testers, to make sure everyone understands what part of the feature is testable.