Today, I tried to run a workshop to gather user stories for a project over in Mt Eliza. (This meeting was also notable because of the ratio, 9-1, of women to men.) I took the approach outlined here which basically suggests several iterations of user story writing, followed by several iterations of writing acceptance criteria. I've run a couple of workshops like this before and a lot of similar things keep coming up which I think limits the benefits. Here are some things I'm going to try next time to help improve these workshops.
Address "How Do this Project Affect Me"?
Many of the users at the workshop are our frontline employees, those with the most to gain (and lose) from any new system or change in process. As with any good IT project, there is always the potential to make existing employees obsolete. Any changes should be communicated to the employees so they can feel secure in their job and comfortable that they can still perform well.
Know Your Audience
In this particular meeting, there was about 15 people there. They all had different needs and requirements, some thinking that this project probably didn't apply to them. An informal catchup with groups of like-minded stakeholders would smooth the user story exercise.
Stories First. Platform Later.
Many IT projects are run in near reverse order: first the technology platform is chosen, then the stories are written, estimated, and prioritized. I've italicized estimated because this is step most affected by your existing technology choices. Quite simply, using off-the-shelf software makes some things trivially easy, while others are outrageously difficult. Choice the platform (or build it from scratch) in a way that will minimize estimates across the board. To be successful here, intuition becomes key since there are and will be just-in-time requirements.
Education Your Constituents
"We don't know what we don't know." "Is this even possible?" "Here's a stupid question:
Before these workshops, we should fill some of these gaps. If we know this is a content management-type project, let's demo three very different kinds of content management systems. If anything, this can be fodder for people's imagination during the workshop. Hopefully, it stimulates discussions between people and their managers and can often put people at ease on the relatively low learning curve involved in new systems.
Come with Examples
It's hard (at least for me) to give good, relevant examples of user stories on the day. Bring a few user stories that were actually implemented in a previous, high profile project. Show the life of this story, from workshop, refinement, implementation, testing and so on. Ask: given this user story, do you think it is done? How could this story have been written better?
Wrap It Up
In the end, these workshops are important, but the project really takes shape after a few of those first stories are implemented. Don't be afraid to change direction nearly straight away. It's way better than throwing something away after it is completely "finished."
4 comments:
Good tips -- particularly the first two because, at this point, it's all about people. And by "people" I don't mean "users of the system" I mean "employees who need to get their jobs done as effectively and efficiently as possible."
One thing that works for me, by the way, is that when I don't have a good or particularly relevant example to share I try to extend (or slightly embellish) a less-suitable example to fit the current situation. I usually say something like "I can give you an example in which something similar happened..." and then I narrate the actual example. After that, I extend or adjust that example to suit the current situation. The audience understands that my example is imperfect, but they usually get the point I'm trying to make anyway.
...please where can I buy a unicorn?
Post a Comment