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.
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 learning.anaplan.com 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 Hubis extremely handy for this. The most critical information in the user stories will come from the organization’s SMEs.
In my experience, the most successful Anaplan projects are those which allocate 25% 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 4 weeks to requirements and user stories. How does that 25% figure compare to your expectations?
There is 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:
The rigor inherent in these user stories justifies a large time investment up front.
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 the 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:
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 “re-do’s” in the middle of the build, ultimately pushing the build well past deadlines for model testing and go-live.
More from Spaulding Ridge:
In summary, here is my list of tips for allocating time to 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 2 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.