A Good Plan: Spend Time on User Stories
In this guest blog series, Anaplan partner Spaulding Ridge examines what they have found to be integral parts of a good plan: the level of detail, the process, the people involved, the timing, and pitfalls to avoid.
Writing user stories is one of the most impactful and exciting phases of the early Anaplan implementation process. It also needs to be one of the most thorough.
The Importance of User Stories
In the Agile development framework, a user story is one of the final steps of the project’s Requirements phase. At this point in the project, the organization has decided on the ideal level of detail of the solution and the scope of the organizational changes; including considerations for potential impacts on all stakeholders—more to come on that topic later in this blog series. At this point, the Scrum Team and the organization’s Subject Matter Experts (SMEs) are prepared to write user stories.
Quick Reminder: A user story is a detailed description of a requirement containing the information needed to estimate the level of effort to fulfill the requirement, and for the developers to understand what exactly to build. Regularly visit the Academy to refresh your memory!
User stories can seem a daunting task. These are, essentially, the roadmap that the developers follow and measure against for the rest of the project. Fortunately, user story shells and formats are typically provided by the Scrum Team; Anaplan’s Project Management app on the App Hub is extremely handy for this. The most critical information in the user stories will come from the organization’s SMEs.
How Much Time Do I Need?
In my experience, the most successful Anaplan projects are those which allocate 25 percent of the total timeline to requirements alone. Thus, if your project’s scope of work (SOW) specifies 10 weeks of build and user acceptance testing (UAT) with one week of launchpad training, then you should allocate at least four weeks to requirements and user stories. How does that 25 percent figure compare to your expectations?
There is a good reason for this. Sorting requirements into user stories requires a large time investment from the team early in the project. Each user story must:
- Add value to the organization.
- Be able to be prioritized with respect to the other stories.
- Have a thorough description, but not so much detail that it limits understanding or clouds the objective.
- Have definitive acceptance criteria so that the builders and SMEs can agree when the requirement has been fulfilled.
The rigor inherent in these user stories justifies a large time investment upfront.
Talk It Out
Another time-consuming aspect of story writing is the necessity for agreement. Each individual has an idea of what they want and what deserves priority. These ideas can knowingly or unknowingly be at odds with others. How do these competing opinions reconcile? We can accomplish this only via interpersonal conversation. A whiteboard and markers certainly help, too.
Conversation is what drives agreement among all parties, and this can be very time-consuming. Good leaders should encourage these conversations, however tough (and sometimes painful) they might be. Successful outcomes can only be reached when the organization faces and resolves tough questions. Project managers and sponsors need to be aware of this and allocate time for lengthy and detailed conversation into the project plan.
From my experiences, here are the top reasons to spend adequate time on writing user stories:
- More time spent discussing stories as a team results in higher levels of collective and individual understanding.
- Longer and more frequent conversation allows for more voices to be heard.
- Thorough consideration of multiple perspectives and solutions increases the likelihood of making the best possible decision.
- The significant time investment strengthens the internal team’s feelings of ownership of the solution, increasing the likelihood of adoption by the organization after go-live.
- Level of effort (LOE) estimates become more accurate, reducing the risk of delays and unexpected roadblocks.
- The team’s confidence in the project grows, fostering enthusiasm and momentum when the build phase begins.
A Word of Caution
What happens when the project team decides to neglect the user stories? I’ve seen clients increase the risk level of the project in many ways: by leaving acceptance criteria blank, beginning the project with stories written but not reviewed, and “rubber-stamping” sponsor approval. The more time you invest up-front, the less pain the project team endures later in the project.
One of my clients identified a need for standardization and automation of their incentive compensation process. Each member of the client team was confident that they agreed on the implementation goals, the inputs, and outputs of the compensation component formulas, and the many reports which would support managers in the process administration. Thus, we were told, there was no need for them to review the user stories once they’d been written and no need for the client team to input acceptance criteria. Our team had questions about certain user stories and marked them “TBD” when the client team was unavailable to discuss them. However, pressure from executives and contract deadlines rolled the project into the build phase anyway.
During the build, questions had to be answered to deliver the functionality. In many cases, the members of the client team had different ideas and expectations of their own internal processes. These realizations disrupted the build activities, and the project team had to have lengthy conversations and whiteboard sessions about requirements. These discussions led to many architecture changes and work “redos” in the middle of the build, ultimately pushing the build well past deadlines for model testing and go-live.
More from Spaulding Ridge:
Keep It Simple
In summary, here is my list of tips for allocating time to user stories:
- Answer every question. “To Be Determined “TBD)” and “will follow up on this later” are examples of phrases which should never appear on any user story.
- Leave no field blank. Who, what, why, how, description, and acceptance criteria each play a unique role in defining the user story.
- Get signoff from the project sponsor on each user story before the build begins.
- Make sure the assigned builder has a complete understanding of the story and acceptance criteria.
- Allocate 25 percent of your project timeline to requirements and user stories.
What experiences have you had with user stories? How have you seen the amount of time spent on them impact the overall project—either positively or negatively? Let us know in the comments and leave your questions for Mitch!
Mitch Aist, Master Anaplanner and Senior Associate at Spaulding Ridge, LLC, has been building and solutioning in Anaplan for nearly two years. He has worked extensively with incentive compensation, FP&A, and sales performance management (SPM) use cases, in Anaplan and other cloud applications. Mitch delivers tangible value to client organizations using this experience and his thorough knowledge of the Anaplan tool. To talk more with Mitch about user stories or other Anaplan-related topics that are important to your organization, contact him via email or on LinkedIn.
Comments
-
Thanks, Mitch! Great content.
0 -
Thanks!
0 -
Great advice.
0 -
Hey Mitchell. Great article and tips on writing user stories. But I believe that writing any content requires special skills, talent and experience. This is not suitable for everyone. Medical topics are especially difficult and often students of such colleges use nursing assignment help from professionals on special online platforms. I believe that such help is very important for every student, especially during practice, when there is no time and energy to write such content.
0
