Contact Us   |   Sign In   |   Register
SAS Blog
Blog Home All Blogs
Welcome to our SAS general blog! We encourage you to participate!

 

Search all posts for:   

 

Top tags: agile  change  Change Management  implementations  management  SaaS  scrum 

Limit scope-creep and create buy-in for projects with user stories

Posted By Melinda Starkweather, Monday, April 18, 2016

 

 

 

SAS White Paper          

4/18/2016

 

 

What happens when someone on your team realizes halfway through a technical implementation that he completely forgot about a really important part of his job? That requirement needs to be tacked on to the project and the project scope creeps.

 

Scope creep means more time, more money and more disruption. How can we limit it?

 

When adopting technology, one of the more challenging steps is planning the transition. An essential part of this is getting users to recall all of their essential tasks, so those can be included in the new system. It’s human nature to forget a thing or two. We also want successful implementations where users buy-in to the change instead of resisting it.

 

User stories can help with both. The idea of user stories came from Agile software development and Scrum management practices. (Because we run SaaS adoptions, we use aspects of Scrum a little differently than when it’s used for development.) User stories are an elegantly simple idea. A person creates a short, 1-sentence narrative about a specific task they need to do.

 

Here’s an example:

 

As a (type of user), I want (to do something/something), so that (value). 

 

As a lumberjack, I want a large axe so that I can save a girl and her grandmother from a wolf.

 

Each story creates a project requirement or task.

 

Most people enjoy talking about themselves and what they do. They get to justify their positions and authority in the organization. When they can describe their responsibilities as a story: “As a ________, I need/want _____________, so that I can _____________”, it’s easier than creating a bullet list of requirements.

 

Their user story creates context and sparks memories. As the user talks about their tasks, they remember and add more details. As users create their stories, the exercise stimulates “context priming” which helps them recall more associated stories.

 

A really great tool for this process is Trello. Developers commonly use sticky pads to write out user stories then group them in organizational threads. Trello is like an E sticky pad.

 

It’s our experience that the most risky piece of every implementation isn’t the technology. It’s the people. While technology works logically and accurately, people can get emotional, touchy and resentful of change. Human beings don’t simply shift with each new command line. (If only it were that easy.) We’ve seen people turn a project sideways when it ran counter to their self-interests.

 

One of the techniques that we’ve found to be beneficial is change management. 

 

Change management has several practices to help the “people side” of change, but one of the primary tenants is to get team members to buy into the future vision and feel like they are a proactive part of it.

 

Change brings disruption and threatens control. By having team members create user stories, they get to drive change in the direction they need. They control the parts of the implementation most important to them. Giving users a voice and listening to their needs will expedite their enthusiasm for a project.

 

Because these stories are relevant to the tasks that fill someone’s day, creating them drives project buy-in from the users, and incorporating these into the project establishes incentive to actively participate in the change process.

 

If you regularly install a specific SaaS or other technology you often see repeating patterns.  A great way to use these patterns is to create a list of user stories for selection. Recall is a more difficult cognitive task than recognition. By creating a list of user stories to select from, you limit the difficulty of the cognitive task, allowing more energy to go to recalling other user stories, unique to a user’s experience. The more detailed user stories you have, the more the user feels in control of the change, and the more likely his buy-in and cooperation with the implementation. The more complete the user stories, the more complete the list of requirements. When this happens, the less scope creep tangles up a project.


To sum it up here is one of my user stories:

 

Melinda Starkweather, CMP is a partner with Starkweather Association Services

She practices and writes about bringing change management practices into smaller organizations.


 

Tags:  agile  change  management  scrum 

PermalinkComments (0)
 
Membership Management Software Powered by YourMembership  ::  Legal