Two years ago I was involved in a large software development project that included developers, architects, and systems analysts. The team was organized into a scrum team along with corresponding product owner and scrum master. There was a lot of optimism and energy during the forming stage, as usual, but all of that quickly came crashing down in execution. Despite the team’s storming phase there were a lot of accomplishments and the team successfully delivered on its mission. One thing that remained a constant problem was how to effectively use systems analysts in scrum to develop and deliver user stories to the larger scrum team.
The issue was not the systems analysts’ inability to do their jobs. The problem was that there was not enough lead time for analysts to dig and discover information. Information that is needed to further develop the product through the creation of user stories and acceptance criteria. Developers need to know how and why something is needed. The analysts could articulate why something was needed but never seemed to have the time to understand the how. Knowing the why part allowed for the creation of user stories. Not knowing the how meant that acceptance criteria was sorely lacking.
The project eventually ended and I left for a new destination and new projects. However, I kept thinking about the issue of how to use analysts in a scrum team. Should analysts just become product owners? Perhaps, but that didn’t seem like a real solution due to the complexity and size of many systems in today’s IS (information system) organizations. I read countless blogs, all of which had no clear answers. I talked to scrum masters with all levels of experience. I was looking for answers with tangible working knowledge. Something like a roadmap that could be turned into a framework for organizations.
I finally found a solution at ScrumAlliance.org. Sometimes the best place to look is right at the beginning.
The framework involves employing a separate scrum team to develop requirements and feed them into the product backlog.
I know… The answer was so simple.
I’ve been coaching scrum teams in this model and the feedback I’ve been receiving has been very promising.
Step 1. Form the Scrum Team
The product owner and scrum master should be the same product owner and scrum master found on the primary product scrum team. This keeps things consistent across the two teams and it adds very little overhead to the product owner and scrum master since the work supports the same product. However, this scrum team doesn’t have any developers. Only systems analysts (or business analysts) form the core scrum team.
Step 2. Define Product Features
The product owner develops objectives and features for the product. Systems analysts should participate in this stage to understand the needs of the business. These objectives/features need to be prioritized into a requirements backlog. The product owner should continuously groom this backlog to ensure it stays relevant and focused.
Step 3. Sprint
Sprints are executed in the same manner as other sprints. I suggest a 3 to 4 week sprint (4 weeks seems to work better in my experience but do what works for your organization). Follow all of the standard scrum ceremonies with the only difference being the standup. Rather than a daily standup just hold a weekly standup. Timebox this ceremony with the usual 15 minutes.
So why do a weekly standup?
The work analysts do takes time and rarely changes from day to day. The deliverables an analyst produces are broad. Impediments are often associated with needing to have meetings with people, taking time to read supporting documents, or just simply playing with an existing system. Analysts produce things over weeks, not days like a software developer.
Step 4. Create User Stories and Documentation
The outputs of sprinting are user stories and any supporting documentation your organization requires. Many organizations still require BRDs (business requirements documents). I find it best to take the user stories and build them into document. Just high level user stories (i.e. epics). The user stories the analysts create will likely be large anyway—that’s okay. Building a BRD with epics lowers the likelihood the BRD will require major revisions once it is published.
Here’s the tricky part.
Organizations need to accept that the BRD is a living document up until the project reaches a certain point. That point will differ from project to project, but it will likely occur before a major release. If you publish your BRD for each major release you will have multiple BRDs rather than the singular one that PMP practitioners demand.
Organizational leaders are so accustomed to having a BRD before work begins. This belief is rooted in tradition (We’ve always done it that way.). The real reason BRDs are published before work begins (historically) is to provide control for the project. In the context of scrum there is control. The product owner is overseeing the development of user stories and approving or rejecting the deliverables.
The BRD serves to communicate requirements of the product to managers, regulatory bodies, and other stakeholders external to the scrum team. User stories are the true requirements used to build the product. However, the user stories the development team uses roll into the BRD’s user stories (remember you included epics in the BRD and not decomposed user stories/tasks). Product owners and scrum teams should maintain a traceability matrix between features & epics (elements published in the BRD), product backlog user stories (may be smaller than epics but still too large to complete in a single sprint), and sprint backlog items (decomposed user stories to be completed in the development sprint).
I find little value in tracking all of the tasks that may be associated with a user story. These often change based on variables such as developer knowledge, technology constraints, and present day goals. If you were to perform the same project a year from now the tasks will likely be completely different. Don’t add them to the traceability matrix unless you absolutely have to (you just increase your workload if you do). Besides, traditional BRDs don’t include tasks anyway.
Conclusion
This framework gives analysts the time they need to develop user stories and dig into a system to really understand its function and interactions. It also allows them the ability to work ahead of the development team. Since the analyst scrum team isn’t creating workable software, they can publish their user stories (with acceptance criteria) as often and as fast as they can create them. They shouldn’t wait until the end of their sprint to add items to the product backlog. Adding an item to the product backlog is the definition of done for this analyst scrum team. Rather than performing code review, schedule time with the product owner for user story review. The main focus should be about feeding the development scrum team user stories so they can keep developing workable software.
Well that’s it. You can see the framework below. I can only take credit for the creation of this image, but not for its concepts or design. I adapted it from ScrumAlliance.org (which you can see here). I needed a large version I could work with and the image on ScrumAlliance.org was just too small to be usable.