4

I'll give the context first: 8 DEV + 2 QA team working Agile, more specifically Scrum. We use Jira for the project backlog and AzureDevops for code. Every story is tracked in Jira and we also create tasks accordingly in as sub-tasks for the User Stories that we will implement during the sprint and once they are finished the story will advance naturally to Done in the end.

The new Scrum Master (SM) suddenly decided to copy the whole backlog to AzureDevops and ask the devs to track their progress for those sub-tasks in AzureDevops and Jira will be used to track and keep only the User Story but not the subtasks.

I find that this "double backlog" a burden on the team and even the synchronisation between the two systems is hard (might even name it an anti-pattern).

Does anyone have any feedback regarding the gains (productivity-wise or otherwise) that this 'double backlog' could bring?

Update: I'm adding more context and the explanation we had. First we work remote because of the COVID-19 situation. SM's explanation was that "We are wasting too much time to update the Jira board and we need it to be up to date for each Daily Scrum. So we need to add tasks on the board easily if we identify more work to be done and find the tasks easily. We need to have a tool created with this in mind".

I might add that the sync Jira<->azure devops is being done manually.

4
  • 7
    The new Scrum master suddenly decided to copy the whole backlog to AzureDevops... Why? Have you discussed the reasons? What are they trying to do with this action?
    – Bogdan
    Apr 1, 2020 at 20:05
  • 2
    This is something that you need to discuss with your colleague. We really can't help you with what your SM decided to do. Undoubtedly, (s)he felt that (s)he had good reasons. Just ask! Apr 1, 2020 at 21:01
  • 2
    I agree with @Bogdan and assume the rest of the team feels the same way you do, so speak up as a team or use the retrospect if that feels more safe.
    – Bart
    Apr 2, 2020 at 4:41
  • 1
    i've added an update to show the explanation that was sent in an email, why we needed another backlog for the same items in jira.
    – alexmage
    Apr 2, 2020 at 15:16

3 Answers 3

4

I initially didn't want to answer this question since the comments do a proper job of capturing the gist of it (i.e. discuss it with your SM/colleagues), but since I don't like neither of the currently existing answers, I'm just going to throw a wrench into the works here.

One of the answers basically says "How does the Scrum Master dare to do this", while the other answer says something like "You don't like it? Tough. Just suck it out and do it". Let's expand a bit on this.

First of all, as it happens with a lot of stuff, many things are situated on a spectrum. The existing answers touch on the ends of the spectrum. For example, the Scrum Guide says this about the development team:

They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;

This makes Barnaby's answer correct but somehow at one end of the spectrum: the Scrum Master has no right while the team has all the rights. Then we have Mike's answer where it's stated that:

The SM might well be responding to corporate accountability expectations "form above" which ... Must Be Obeyed.™

Which is also correct, but again, at the other end of the spectrum. This negates the characteristic of self-organization you have in Scrum, because it says that you must do whatever upper management tells you.

Let's think about the full spectrum now.

In between these two ends, you have a full range of possibilities. The Scrum Master (SM), since they are responsible for this whole Scrum thingy implementation, might have decided that this will help the team, but forgot that they are a servant leader and they should not take decisions without consulting with the team. Maybe the SM, in their own work, find this setup easier to handle but neglected to think what the impact will be on the rest of the team. Maybe the SM is a SM with just the name, a Project Manager in disguise, if you want, and they have the bad habit of doing what they want. And, yes, maybe the SM needs to present reports or what not to upper management and this setup helps them extract better data. And so on. You don't know the reasons until you discuss it together. Once you understand the reasons, only then you can decide what to do next. Stick with this setup, go back to the old one, find a third alternative, etc.

So discuss the reasons. You can do so at the retrospective, or you can just raise the point up with the SM when you have some time available for a chat.

With that being said, the SM also serves the organization, not just the development team. That means that if management decides to do something that badly impacts the development team, the SM should open up a discussion about it. In true Scrum implementations, upper management must interact and collaborate, not spit out orders to be followed. It's the SM's job to try to help the team while they are also responding to requests from above like reporting, status updates, etc. By discussing it with upper management, you can reach a conclusion that can satisfy both parties. But you have to discuss it.

If upper management doesn't care, they can impose stuff. That's why they are upper management. As a team you will then have to accept it, since you work there and are paid to do a job, and following upper management directions is part of your job. But if people in the team really want to use Scrum properly because they understand its benefits, but upper management decides to play by other rules, then they might get pissed off and decide that they go work for another company with the proper Agile values. And when people leave, it will have to be upper management this time, to accept the situation.

So once again: discuss it, find out the reasons, and figure out together what the best solution is given the situation.

EDIT: my comments on the SM explanation:

we are wasting too much time to update the jira board and we need it to be up to date for each daily.

Why are you wasting too much time to update the Jira board? I understand you are now working remotely, but when you were in the office weren't you using the Jira board? Was it fine then? What changed now?

So we need to add tasks on the board easily if we identify more work to be done and find the tasks easily.

Tasks are second class citizens compared to their parent user stories. You implement user stories during a sprint. Why is it so important to have tasks attached to stories and track those tasks? You can communicate about stories and their completion without tasks. I'm not necessarily suggesting you give up on tasks (it's your team, your policies, etc) but I've always found tasks to be an operational overhead and sometimes hide large stories (a large story with 2 tasks, instead of 2 stories).

we need to have a tool created with this in mind

One of the Agile values is "Individuals and interactions over processes and tools". You're jumping straight to tools here. This raises some red flags. You are trying to solve a problem by manually synchronizing boards and then you need to write a tool?!? Seems to me like the solution is worse than the problem you are trying to solve.

1

The new Scrum master suddenly decided to copy the whole backlog to AzureDevops and ask the devs to track their progress for those sub-tasks in AzureDevops and Jira will be used to track and keep only the User Story but not the subtasks.

The Scrum Master has no right to make this decision.

There is nothing in the Scrum Guide or in any other definition of the Scrum Master role that gives them this kind of authority.

They can make a suggestion of a new approach to the team and then it would be up to the team to decide if they wanted to adopt it.

I think the actions of the Scrum Master are a more pressing problem for your team to resolve than the way JIRA and Azure DevOps are being used.

-1

"Unfortunately, Barnaby, I don't think that's Corporate Reality."

The Scrum Master, whether or not you choose to call him/her that, is a Manager. Obviously, the motivations for making such a decision deserve to be questioned with him-or-her, since they fundamentally affect the daily operations of the team ...

... but to say that it is actually(!) "up to the team to decide if they want to adopt it?" No. The SM might well be responding to corporate accountability expectations "form above" which ... Must Be Obeyed.™

Perfectly fine to ask, "Whatsup?" But you'll have to accept the answer.

5
  • 1
    Are you actually saying that the Scrum Master is a manager? Or that they can sometimes act as such?
    – Bogdan
    Apr 3, 2020 at 8:11
  • 2
    Not to be harsh but this is just wrong in terms of actual Scrum. It seems to be describing a common failure case of implementing Scrum where project managers are renamed to Scrum Masters but don't actually carry out that role. A Scrum Master does not have the ability to impose decisions like this upon a team and isn't a manager in the sense you're describing. Even if there were "corporate accountability expectations" which needed to be followed by the team, it would be up to the development team to respond to and meet those expectations. Apr 3, 2020 at 11:11
  • I'm confused why this Answer was flagged for deletion. Sure, the Answer is obviously wrong, but I thought that was cause for downvoting, not deletion?
    – Sarov
    Apr 6, 2020 at 13:39
  • @Sarov the question seems to be "Is this [having two backlogs] something that someone is doing and do you have a feedback about the productivity gain it brings ?" but this answer doesn't address that, it's about whether a SM has the ability to impose this on a team. Which is an important question but not the one that was asked. Apr 6, 2020 at 14:38
  • 1
    @RuaidhríPrimrose I see your point, but in a similar context a similar Answer may be correct. The OP is asking "Are there any benefits to X?" The answerer is replying "It doesn't matter and you're asking the wrong question." To me, that's a frame challenge, which is often the correct response. Thus, I see this Answer as valid, just incorrect.
    – Sarov
    Apr 6, 2020 at 19:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.