We recently facilitated our Crafting Agile User Stories workshop to a client who’s teams were already pretty high functioning with Agile methodologies and Scrum.
The course was a success; we achieved another 80% NPS result. Although most members of the teams were very familiar with Agile User Stories, they felt the course and activities taught them a variety of new things that would help mitigate some of the challenges they were currently facing and they would be able to implement on their Agile Scrum teams.
There were a couple of activities in this course that really excited the teams. Since completing the training they have told us how successful they have been implementing these Agile user story practices into their projects. These are the User Story activities I wanted to tell you about in this post.
Story Mapping to Elicit Agile User Stories
Story mapping takes a user-centric perspective for generating a set of agile user stories. The idea is to start with a high level user activity that we will call an epic, break it down into a workflow and then break it down further into tasks. Deferring the “how” (tasks), until the last possible moment.
The teams had already developed a product backlog of agile user stories using a particular example we provided, then we asked them to reorganize the existing stories into themes, and use the story mapping approach to elicit more. What they found was this was a very effective way to visualize the flow, identify gaps and pull out a comprehensive backlog of user stories.
Since the training, the teams have deployed story mapping as a way to elicit requirements in combination with the techniques they had used previously. The result is that where previously they worried they may be missing something, they are finding they now have a lot more confidence the product backlog is complete to the extent there is “enough” to get started.
Affinity Sizing of Agile User Stories
We use affinity sizing when we have a large number of stories and possibly a large number of estimators. The way we did it in the User Story workshop was by having the teams record select sizes from the modified Fibonacci sequence typically used in Planning Poker, and then the team goes through each user story and groups them under a particular number. It is a streamlined way to attach a relative size estimate without the potentially time-consuming effort of playing Planning Poker.
The teams really liked this activity in the training because they could work through such a large number of stories so rapidly. Since the training, the teams have found this approach has produced more accurate results, since a large number of agile user stories are grouped on the sizing board and may be easily moved around as new information is discovered. For example, when they find they need to adjust the sizing scale due to some outlier stories – small or large. Re-estimating using Planning Poker is frequently not done because people either cannot see the need when there are a lot of stories, or they are overwhelmed with the idea of doing it. Affinity sizing lets teams approach a large number of user stories and not get “lost in the weeds”.
So, my point is this…we recognize the value in retrospectives to reflect on our sprints and commit to continuous improvement but sometimes it gets difficult to step back and get an overarching view of things because we are so involved. It’s worth thinking about getting an experienced third party to share some of their ideas and experiences, whether it be by taking training or talking to an external consultant a peer, or all of the above. In the case of this particular client, their whole reason for contacting us was to get an external perspective on user stories, to see how someone else does it so they could continue to get more benefits and improve their already successful agile teams.
Thanks for your interest,
Lynda Todd
Manager, Learning Services
ltodd@.scrummasters.com
Scrum Masters Inc provides expert Software Development Life Cycle process improvement.
The services we offer include: