Deploying any technology can be challenging and fraught with multiple uncertainties that need to be managed. Like any other technology deployment, a Salesforce roll-out requires investment of time and financial resources from client stakeholders that already have limited time and budget.
On the other end of the project, development resources that are configuring the environment often lack the level of clarity to deliver effective solutions for the client. The developers are unable to visualize the user experience and are left to make assumption on how the solution would be used. Without this, we often see a solution that misses its target regardless of how elegant the interface.
To ensure a deployment is successful and avoid frustration both from the client and your development team, a Solution Architect needs to be able to capture the User Story from the client and convey to development team. In simple terms, a user story is a combination of what the client is asking for and how that can be achieved in the context of the system in simple non-technical language. The story needs to balance the need of the client stakeholder to understand how the system will behave while providing development resource enough information to be able to translate it into the technical scope that needs to be implemented.
So, what are the ingredients of a good user story? What needs to be taken into consideration in order to bridge effectively between the technical and the non-technical, the business and the developers? There are 3 critical ingredients for user stories to be an effective tool in your Salesforce project:
Leads to conversation: creation of a user story is meant to be an iterative process, with each iteration progressively clarifying and guiding until all parties involved are fully aligned. Clients should be able to quickly understand the story, and be simple enough for them to comprehend and provided feedback. Beware: a user story that doesn't solicit feedback might be one that has not been properly understood by your client. Make sure you test that to ensure development doesn't precede client engagement with the user story.
Has specifics: the user story should have the specifics of how the application will be used without getting technical. It should have enough details in non-technical terms that would allow a developer to create a set of development tasks and provide estimate on the level of effort needed to develop it. Beware: a user story that is too generic for your development staff to understand how they need to proceed. If your development staff cannot proceed without you after reading the user stories, you missed the mark and need to be more specific next time.
Is right sized: a user story should be sized to your development sprints. A user story should not be excessive broad to span multiple sprints, nor unduly narrow to require no attention. Where needed, a larger development effort should be broken into multiple stories to help teams stay focused. Beware: creating a user story when it is not needed. If you have something that is very clears which doesn't need conversation, you can bypass user stories and create your development tickets directly.
Comments