How to manage analysts work in Scrum which work for future sprints
Hello all!
I have a Scrum team including 2 system analysts besides PO. We work in 2 week sprints. Analysts analyse requirements and make documentation for developers for future sprints. The question is how to plan and manage their work if they don't work in current sprint? There are 2 questions: The first is about estimating user stories in story points. So as i understand they don't need to participate in user story estimation, cause anyway their work isn't included in the sprint velocity cause they work for future sprints. But here is another question, should we estimate analysts's work additionally in story points to understand particularly analysts' velocity? The second question how to commit their user stories into the sprint, if these user stories include only analytical tasks, is it correct to include these tasks as well? Or should we implement additional board for them? If someone have the clear vision of organising the work of analysts which work for future sprints please share your experience and give me advises.
Thx in advance.
What do you think about having these sub-roles, each with their own skill silos and responsibilities? What does the Scrum Guide have to say about this matter?
Also, if future work is being considered, shouldn't that be handled in Product Backlog refinement?
A Scrum Team should have all the skills to do the PBI, analysis included. Why don't you join your analysts to the team and let the team doing the analysis and claim that work in a task attached to the PBI. And the analysis should be done at the beginning of the PBI during your sprint backlog not for a future PBI.
If you do that it will solve the 2 problems you seem to have.
My scrum team is not cross functional as scrum guide recommends so I have to work in the provided environment. And I guess it is not easy to make it cross functional cause every person in the team is a unique with their own skills. We have groomings for sure , but should we estimate user stories with analytical tasks separately in order to calculate analytics velocity or not? How better manage their job? Should we include their job in sprints or should their work outside the sprint or in their own sprints?
It looks like they are helping your PO for preparing the Backlog. Why do we want to include them as a part of Scrum team?
Let the PO and the analyst plan their work separately
Analysis work is quite complicated in this project , cause it's a banking system, so cause of that the analysis is done in advance and after, in Sprint planning meeting, analysts describe which functionallity is expected to be done in the sprint. After a sprint starts they start analysing future sprint in order to prepare some documentation for developers. So here is a main question how to manage analysts time / effort in story points, create additional PBI which contain analytical task or just don't manage their effort at all?
How they are different from the PO?
They write detailed documentation for developers while PO just sets the direction. If we don't estimate their effort so we won't know how much analysis they can prepare untill the next sprint, right?
My initial reaction would be to make the documentation and analysis into PBIs. Make the analyst part of the dedicated team. If their position is crucial to creating the software, then I would consider them to be a developer.
I think that you should look at the documentation as part of the overall process. Yes, it is not utilized until the next sprint, but it is still part of the overall "machine" that is producing software. So if you think of it as that kind of entity you can apply story points to it.
And if they creating documentation from the backlog they will eventually become better at predicting their velocity and working with the team.
And as far as including them in with the whole teams velocity or not, that is a call you need to make. It really depends on how integral that analysis is to the process (which I know nothing about your process).
Hope I provided some sort of insight though.
The PBI or a user story is considered done based on Done criteria such as tested, developed, documented etc. How can we include the PBI which contains only the task of documentation into the sprint. At the end of the sprint we wouldn't consider this PBI as done cause it covers only 1 issue such as documentation. Or should we make 2 PBIs: 1 for documentation , which we include in the current sprint and the second for developement, tests and implementation in the next sprint, is it ok? Cause if it's 1 PBI for all issues then, let's say we estimated a PBI by developers , testers and analysts. Then, analytical part we will do in one sprint and developement, testing and implementation in another. So how can we understand how many story points were spent for analytics and developement? So in this case we can't estimate the effort spent for PBI in the sprint, cause analytics work has been done in the previous sprint and remaining work in the current sprint.
I would agree with Ian, I consider the work the PO and analysts are doing as refinement therefore managing that work within its own Sprints seems like wasted effort but if it is adding structure and optics necessary in your org it can be valuable. I think it would be OK to model the two analysts that help the PO manage the PBL as subject matter exports that are "outsiders" to the Dev Team. That said, whether you consider them part of the Dev Team or not, ideally they should be available to the Dev Team during their Sprints to provide context and answer questions, i.e. hopefully your arrangement is unlike a phased approach (e.g. Waterfall) where large analysis effort is done and then "handed off" to the developers followed by the analysts moving on to "other things" and not being there to support the developers. Whether these analysts are officially Dev Team members or not might be an irrelevant point but I would definitely work towards ensuring there are plenty of zones of collaboration between the analysts and the official Dev Team members.
An alternative thought - I don't know how big is your development team, does it make sense to divide it into two teams and let these analyst work as a PO with each team. They can coordinate with stakeholders for prioritization purpose and keep working with the Dev Team for refining the Product Backlog
I am leading team of BAs in banking environment and I am solving same issue now. I am came to conclusion that SCRUM is not a good framework to support analytical especially Business Analysis level and architecture work. It is not intended to support it, you always have to find some workaround.
BAs are not part of development scrum team and for me, it should be different board to measure velocity and drive work. We have monthly sprints but me and my analysts are working on stories which will go in next 6 sprints. In different level of details.
My workaround are analytical stories. Analysis leads to dead end, or postponement of the requirement until business process is adjusted or clarified and it is still valid output of analysis and analysis has been delivered without any development work. So I am using analytical stories to estimate analytical work, track stages of that work. For story which leads to development, definition of done of analytical story is Dev story or s refined in backlog, ready to be taken for development.
Treating analytical work as different team pretty much.