Allow Sprints to be planned in PLANNING Status

[#1]

When creating new or modifying existing stories, an email is sent out each time to every person in the Agile Team. Since this is done during a Sprint PLANNING meeting, Workfront should allow the backlog to be visible in PLANNING status but one can only view backlog in WORK IN PROGRESS Status which is not the state which the project is in. This will allow the hundreds if not thousands of keystrocks and mouse clicks necessary to set up a Sprint to NOT send hundreds of emails to the team.

[#2]

To add to this issue

The use case:

I sometimes function as a scrum master. Weekly, I stand around a table with team members or other managers and we plan sprints. We pull up the backlog page and add stories as we discuss. Then we go through and evaluate what we just added. We delete some, we add others, we re-name some, nothing unusual for a sprint planning session.

Then I walk to the team area and they mob me because they each just got 50 emails, one for every story we created, even the ones that we promptly deleted. Soon they stop paying attention to the emails. Then they create spam filters for them and ignore notifications altogether. This is a problem.

Since I know that when a project is in planning the emails are not sent for every change, I try putting the project in planning to prevent unnecessary emails from being sent while we plan the sprint. However, the entire backlog disappears because projects in planning do not show up on the backlog! So I can’t do the sprint planning from the backlog. I think we should be able to as would any agile professional think the same.

So we try planning the stories as tasks on the project while it’s in planning. Then I turn the project current and the stories still don’t show up on the backlog. At last I realize it is because we didn’t assign the tasks to the agile team (but stories created from the backlog show up on the backlog even though in the task view they are not assigned to the team!! So confusing!). So, I go back to the project to assign the tasks to the team and then it sends the email and then they show up in the backlog. That's a lot of steps and a big workaround within a tool that is renown for its high burden of clicks and keystrokes to begin with.

As scrum masters, all we want is to manage stories from the backlog, not from the project. And users don’t want to get emails for stories that are not going to happen.

So, for the time being, when we do our sprint planning we can use this workaround: At the beginning of our weekly planning meeting we will go to Setup and turn off the notification for “Work Item Request to Team.” We'll do our sprint planning from the backlog page, and then turn the notifications back on when we’re done.

It’s not an ideal workaround for us and it should be changed immediately regardless of "votes". The idea of a repository for these things are great, but the reality of the repository is that it is spread out, unlikely to get a lot of hits outside of ones organization.

[#3]

Hi Bob,

As as suggested solution to your problem, you could assign a job role to the task while you're in your planning meeting and then only when you're ready for the developer to be notified of the work, add their name as the Assignee.

When I am writing stories for my projects I tend to use the generic Developer role so that my team doesn't become overwhelmed not only in their inbox but also in their Work Requests queue.

Hope this helps!