As part of this training, I was introduced to the Agile project management tool: Mingle. http://studios.thoughtworks.com/mingle-agile-project-management.
I thought I’d post some information about how we are using this tool to fold UX into the software development process here. Since we’ve been through 4 iterations now, we are starting to get the hang of how we all work together.
This chart shows the relationship of cards to a project in Mingle:
This chart shows where UX fits into the Mingle Card Status:
The goal in working with our Agile coaches was to provide earlier visibility to stories that require UX involvement and would reinforce the idea that
UX should work more closely with the BAs and DEVs:
How this Works:
- (Process—UX responsibility) UX monitors the BA tab to maintain awareness of upcoming stories that may require user research and notifies the BA if there are stories of interest. NB: We’ve established here that anything that relates to “front-end” is automatically tagged for UX.
- (Mingle update: “Start Analysis”) BA are prompted to flag the story that requires UX involvement (with help/input from UX analyst). The flagged story will immediately show up on the UX tab.
- (Mingle update: “UX Design Sign-off”) Story that is flagged with UX involvement required requires “UX Design Sign-off”. The flagged story must be signed-off by UX analyst prior to BA marking the story as analysis is complete and ready for development.
- (Mingle update: “UX Development Sign-off” – The UX flagged story must be signed-off by UX analyst prior to DEV marking the story as Ready for QA (which will give the BA a chance do a cursory check to ensure what was developed met the business requirements).
- (Mingle update: “UX Required” field is made editable). The field is made editable and allows Mingle users the ability to update/set the flag as needed
Here is how this plays out in real life so far:
- During Story Analysis : UX participates with the BA in needs elicitation from the user’s perspective to help write the story. UX meets with the BA and the Clients (who are not end-users per se — but that’s another story)
- The BA works with the business owners to decide what stories go in this iteration. He then draws mock-up screens that are added to the story. We are using a Wiki to hold these story pages, and link them directly to the story in Mingle. (We also use Balsamiq to do the mock-ups — that will be another post)
- UX reviews those mock-up screens for best-practice as the developers review for technical viability – this is done through a story review with the team (try to take the form of cognitive walk-throughs here to keep team members on task)
- When enough stories are complete in mock-up, they are linked in clickable prototype format so that our End-Users who participate in weekly revolving door sessions can test. UX does a weekly report-out that includes story sign-off and stories signed off with these exceptions.
- UX also participates in client story reviews at this time to get client feedback on the prototype
- During Development UX does desk-side reviews as the developers are programming the UI screens. We are learning a lot here — since our developers are doing the screen design — we have no formal designer on the team. As the UX person, I am trying to extract “standards” from the 6 developers and post those on a Wiki to try to keep the design consistent, repeatable and predictable. This is our greatest challenge right now.
- As soon as we can, UX brings the “happy path” click through on a device that has been populated with mock-data to the revolving door session users. NB: About revolving door sessions: Generally these sessions always happen once a week with 6 users who have committed to a 30 minute time slot. They look at both prototype mock ups and test the click-through tasks on the device. Often I am working in 2 iterations with these users — sometimes my head spins! I will write about these sessions in yet another post-
- When enough stuff has been developed so that we can get end users on a device to walk through a task in the context of how they would do it — not just following a “happy path” we do a more formal review with users out in the field — drivers and dock-workers. This gets us locked down, UX will sign off, and then we go to QA.
- During QA UX review stories and defects and adds cards as appropriate. We partner closely with QA to make sure that the integrity of the UX is maintained before we go to client sign-off.
We are making good progress. We don’t claim perfection. I would love to hear other stories and experiences to bring to our team. What works for you? What is not working? What resources are available?