Model users are confused by line charts which stop along the x-axis. They need to be trained or instructed that trailing zeros in line charts are not displayed. Please update Line Charts to include trailing zeros.
... View more
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:
A Good Plan: How Much Detail Do I Need?
A Good Plan: Avoiding Scope Creep
3 Traits That Make a Great Anaplanner
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.
... View more
Personal Dashboards: What Model Builders and Administrators need to know
The Personal Dashboards functionality in Anaplan finally grants your users the flexibility they’ve been craving on their dashboards. However, careful administration is needed to fully capture the value for your organization and minimize frustration for both admins and end users. In this article, I will discuss:
Personal Dashboards and ALM: avoid stress for yourself and your users
Understanding your users and building with Personalization in mind
Observe users’ dashboard personalizations to improve your own consulting and dashboard design skills
Personal Dashboards and ALM
When enhancing a live model, administrators often need to make changes to dashboards. With this new functionality comes new risks. As we know, many of these changes will cause all respective personal dashboards to be deleted. In previous Anaplan versions, users would log in after an ALM push to be pleasantly surprised by enhanced functionality. Now with Personal Dashboards, these same users may not be thrilled when they realize they need to recreate their personal dashboards.
The solution to keeping these users satisfied after changes and enhancements is communication. Just like any significant change to the production environment, users should be notified in advance whenever their Anaplan work station is queued for changes. As the trusted Anaplan admin, you’ll also need to be an expert in the kinds of changes which trigger the deletion of Personal Dashboards.
Designing with Personalization in mind
What kind of dashboards do we expect users to personalize? The answer is simply any dashboard containing modules which allow the user to pivot, filter, sort, edit column settings, conditional formatting, or hide/show columns. Ask your Project Sponsors, SMEs, and COEs if their users have a need for Personalized Dashboards. If not, the admin should disallow these changes in the Menu Options of each of the dashboard’s modules.
Another important consideration when building dashboards is whether these users have got the tech chops and engagement level to independently save their own dashboard views. In many cases, some dashboards will be viewed infrequently by one or a small handful of users. In these cases, the Master Dashboard should aim to meet the needs of all of these users without requiring further customization.
The converse to the previous scenario are the large Executive, Planning, and Reporting dashboards which are used frequently by many users, are highly interactive, and contain a great deal of detail and data-displaying modules. These are ideal candidates for personalized views. For these, the model builder can safely assume that all users have a saved view, and should warn them ahead of time when changes are being pushed. The Master Dashboard should still satisfy the needs of the business, but also allow the savvy users to save their own custom views.
Anaplan does not show admins which users have personalized dashboards, nor what they look like. The silver lining to this is that it provides an opportunity to drive conversations about Anaplan, as well as interact and grow relationships with your clients.
Once your clients and users have adjusted to their new Anaplan ecosystem and become comfortable with Personalized Dashboards, model builders and COEs should seek opportunities to ask these users about their preferences. In the long term, these discussions will give you perspective and knowledge about the business process and can help you plan ahead for these preferences when building future dashboards.
Interviewing users about their dashboard preferences is just one way to gain knowledge of the client, build trust, and improve your consulting and dashboarding skills. Each new Anaplan feature should be seen as an opportunity to learn, interact, and improve.
... View more