Managing BA activities in Scrum
Scrum teams rely on a continuous supply of refined (implementable) user stories in order to plan and execute Sprints. Consumption, development and testing of these stories are typically tracked on Scrum boards until they meet the Definition of Done. In order to replenish the supply of "next batch" stories for subsequent Sprints, Backlog refinement activities is both essential and critical to keeping the Sprint train moving. Different approaches have been used to address this but I am curious what others think?
- Should BA backlog management tasks be defined and tracked on the Scrum board? Why so or why not?
- Do you consider BAs part of the Scrum team? Why so or why not?
- What are the key set of tasks that BAs should be engaged in?
TCS
US
Pega's Scrum training suggests that there be a separate "scrum team" for continuous elaboration of user stories in parallel with the development scrum. This could be formalized within the management tool or not depending on the project/company environment with status' configured or adapted (translated) as appropriate. Then the elaboration activity would have its own Scrum board. I like to have a peer review for finding the mistakes that we all tend to make in addition to understanding review and also a PO review. So those could be likened to QA and UAT. Other tasks in the elaboration scrums would be refining the user story template and writing the detail and acceptance criteria. I like to have small group meetings to "rough out" the detail of a user story from a business perspective, have the BA take some time to refine the text and then review in a larger elaboration meeting to get more perspectives. The approach decided upon would determine the detailed tasks. In PMF we have had a spreadsheet of tasks and uploaded them to all user stories selected for a sprint. They can then be refined on a user story by user story basis.
Pega's Scrum training suggests that there be a separate "scrum team" for continuous elaboration of user stories in parallel with the development scrum. This could be formalized within the management tool or not depending on the project/company environment with status' configured or adapted (translated) as appropriate. Then the elaboration activity would have its own Scrum board. I like to have a peer review for finding the mistakes that we all tend to make in addition to understanding review and also a PO review. So those could be likened to QA and UAT. Other tasks in the elaboration scrums would be refining the user story template and writing the detail and acceptance criteria. I like to have small group meetings to "rough out" the detail of a user story from a business perspective, have the BA take some time to refine the text and then review in a larger elaboration meeting to get more perspectives. The approach decided upon would determine the detailed tasks. In PMF we have had a spreadsheet of tasks and uploaded them to all user stories selected for a sprint. They can then be refined on a user story by user story basis.
Regarding whether BAs are part of a development Scrum team I believe they are. No matter the care in writing, there will always be different interpretations of words based on an individual's experiences. The BA and PO are there to explain and may think of different solutions to a requirement as playbacks proceed based on their experiences. The cool think about the Scrum team is taking advantage of all the different experiences to provide the best solution for the business. I believe that on appropriate user stories there should be a task for BA/PO playback. For some user stories, perhaps a BA only playback. I am finding that more and more there is a partnership between business and systems architect to weigh the OOTB functionality with the business need. Pega has a ways to go to make more OOTB functionality configurable rather than forcing OOTB functionality over customization on the business.
This all said, the company/project environment and makeup of the team make all of this variable.
Ericsson
US
I believe that a BA and all BA practices should be included in Sprint, so his User Story which are going through development/refinement or grooming will be part of Scrum board as task items. This will allow Product Owner a better tracking of work and understanding if any specific focus or attention is required.
A continuous DCO is essential to make any Pega Development successful, by introducing User Story Development as part of Scrum board, delivery of User Story to keep a good backlog could be ensured. At same time BA can seek technical assistance inside Scrum which can further save story revisiting due to any technical limitation which BA is not aware. I have observed in many project revisiting same story really hampered project moving and lot many time it not just because OOTB feature many time technical complexity like performance or the way Technical team building product.
L Chase
GB
With tools that allow for functional prototypes to be rapidly built as part of the analysis and design activity, yes the BA is fully active within the Sprint. The BA is also active with investigations for backlog grooming, so the Sprint capacity needs to bear that in mind.
With tools that allow for functional prototypes to be rapidly built as part of the analysis and design activity, yes the BA is fully active within the Sprint. The BA is also active with investigations for backlog grooming, so the Sprint capacity needs to bear that in mind.
The notion that a story can't enter the Sprint until after it is "refined and implementable" is one that comes from outside the culture of tools which allow for rapid, functional prototyping. With a mature workbench like Pega which supplies nearly all the needed functionality OOTB, the BA uses these functional prototypes as a powerful tool to help with analysis and design of the final solution. So, within this toolset, the story only needs to be refined and implementable to the point that there is sufficient information for a first-cut functional prototype (Case life-cycle and user-interface views) to be built. And it's fine if the first-cut functional prototype is built by the BA ( to help in refining the specifications ) before the Sprint begins. But could instead be early in the Sprint by either the BA or an SA. This approach allows for our methodology to be even less Waterfall in style and to allow for much more overlap of the investigations, analysis and design activities (led by the BA) with the construction done by the SA. The functional prototype is continuously refined until it is the final solution, but it also means that the team must see an early prototype as something that may need to be rebuilt in the light of more information gained as a result of the feedback gained from it. So long as the workbench is mature and powerful enough to supply most of the functionality OOTB in a rapid manner and both the BA and the SA know the tool well, this approach is very practical.
Pegasystems Inc.
US
I think LucC0071 identifies the key point. The Pega development platform has two key implications for a traditional scrum approach. First, it often takes less time to build the functionality than it does to specify it. Second, the rapid prototyping means that the build process itself is a good way to elicit the requirements, not unlike the elaboration-construction iteration we all know and love.
I was recently involved in a project in which the needed user stories did not meet the Definition of Ready until well after the start of the sprint, and often they were not "Ready" until after the end of the sprint. To address, we needed to plan the work out several sprints in advance to allow for early preparation of the work that was scheduled for construction and the availability of a backlog of elaborated user stories that were "Ready". This approach was very helpful in making sure that there was a buildable backlog available at the start of a sprint.
This experience also highlights a more general problem in terms of development outpacing preparation. We often assume that the product owner or the business in general will be able to keep up with the pace at which functionality can be developed in Pega. Not only is this is rarely the case, but a delivery plan based on this assumption will often be challenged.
Cognizant Technology Solutions Pvt Ltd.
IN
My answers to your questions based on our experiences similar to yours:
1. Should BA backlog management tasks be defined and tracked on the Scrum board? Why so or why not?
Yes and a No, Divide the team into Core and Non Core team - Chicken or ham. Maintain two boards for the two teams.This can help you track ideas and its progress and at the same time also keep the core team function smoothly.
2. Do you consider BAs part of the Scrum team? Why so or why not?
As the solution 1 above keep it separate from core team and track the same separately.
3. What are the key set of tasks that BAs should be engaged in?
Coordinating for Backlog creation, Maintaining, coordination for Story pointing, prioritization.
Pegasystems Inc.
DE
Although this post is now a few weeks old here are some of my thoughts and experiences made:
1. Within a Scrum team we had a lack of a designated Scrum master...so I (a BA;-)) took care about this additional part. I mainly focused on having the team available for all necessary Scrum artifact meetings. Our team was fully dedicated to Scrum. So in fact I as lucky not to spend too much time on the scrum master topics.
2. As a BA I had also User Stories within a Sprint and so in the Sprint backlog. Those were for example clarifications of requirements or even writing Requirements & Specifications as a User Story preparation.
3. Preparing the Product backlog with all relevant Requirements was one of my main tasks. This was the preparation for a succesful groomng / sizing of the user stories for the next sprints.
4. Currently I am wondering what exactly is the role of an EL within a Sprint as this seems to be unclear. Currently my expecation is that the EL should solve impediments identified by the team...as the EL is not always participating Reviews and Retrospective sessions this is currently an issue for me.