Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

How to manage analysts work in Scrum which work for future sprints

Last post 04:53 am January 24, 2017 by Sanjay Saini
11 replies
02:08 pm January 19, 2017

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.

03:47 pm January 19, 2017

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?

05:54 pm January 19, 2017

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.

05:58 pm January 19, 2017

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?

04:33 am January 20, 2017

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

09:08 am January 20, 2017

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?

09:19 am January 20, 2017

How they are different from the PO?

09:26 am January 20, 2017

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?

02:06 pm January 20, 2017

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.

02:54 pm January 20, 2017

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.

11:13 pm January 22, 2017

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.

04:53 am January 24, 2017

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

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.