Is a 'Private' board realistic in the world of Scrum where transparency is paramount?

[Thayne Munson]

I have a team manager who has issues on his team's board that he wants to be private.  I assume there are ways to accomplish this in Jira but my question is, since Transparency is such a big part of the 'Empiricism' concept is it realistic for anyone to try and privatize some of their issues?  Is Jira really the place for any information that needs hiding?

[Chris Annal]

The short answer is "Yes". I have a project named "Security", and for some very valid reasons, only the person who wrote the issue and a small group of reviewers should see the details of those issues.

[Thayne Munson]

Thanks for the feedback.  It's interesting you mention Security since that is the team that raised this question.  For manager 'John', is it realistic that John would have some issues that are ok to be visible to the team but other issues are not?  I am trying to figure out how to set up that kind of view.  I imagine a specific issue type would be a potential option.

[Paul Stallworth]

"Is Jira the place for any information that needs hiding" is a philosophical debate for later. :)

But you can use Project Permissions and Issue Security to very tightly control who can see which issues.

https://support.atlassian.com/jira-cloud-administration/docs/configure-issue-security-schemes/

Also, Nic Brough gave a really great answer over on this question around setting up issue security schemes: https://community.atlassian.com/t5/Jira-questions/How-does-exactly-issue-level-security-work/qaq-p/745856

[Chris Annal]

I actually followed the guidance from these links when I needed to set up the project I was referring to. Good links!

[Zans McLachlan]

Culturally, I agree that transparency is central to a functioning integrated agile team. The whole point is that everyone is on the same page and that you are ONE TEAM.

That said, if there is a need for this, I'd use an Issue Security scheme to cordon off the issues (inside the project as "Private", available only to users in, say, an Admin role). Then later if you want to expose the issues later you can just toggle to the "Public" level and the issues will appear on your board.

Or just manage in a separate project if this is actual skunkworks stuff.

Good luck!

[Benjamin]

From my own experience, it usually have to do with the sensitivity of the data in the issue. For example, employee personal info, stealth feature, or government sensitive data. 

Hence, why there is a feature called issue level security to provide just that to make sure sensitive info remain hidden to unauthorized users / groups. 

[Isaac Trumbo]

Issue Security schemes done right are marvelous. In the Jira I administer I was tasked to turn a normal Jira Software project into a Helpdesk for multiple internal team and external partners.

Using Issue Security, Jira groups, Workflow Post-functions, each ticket was secure and shareable to the right people or organizations. Jira Service Desk/Management does this for you but Issue Security can be used for other interesting things as well.

[Alexey]

Like everyone said - yes, that's normal in some cases.
You can either make a security scheme or a completely new project and add there people you want.

I had one manager who asked me to create a separate project where he keeps a backlog of his weird ideas, he needed a place to hide stuff and keep the team focused on confirmed items.
I also created a workflow with an end-status called 'escalated' when he moves an issue to that status, automation instantly clones to the main project backlog.

[WW]

Absolutely, Jira can be used for private issues, depending on the use case.  It's not necessarily hiding issues from the team, but there can be a business need to know level of security depending on the company and the type of data going into Jira.

I'm assuming by "private" that you mean issue level security, and not just project level access.

If they're using a Scrum board to, let's say, develop software, and they also have issues they want to track for the developer team's administrative purposes like did they fill out the xyz survey or something like that, then they should have a project project and a team project for the other stuff.  The project manager, business analysts, testers, etc. don't care about the dev team's administrative tasks (unless Jira is being used for capacity planning, but there are ways around that, too).

If the manager doesn't really need "private" issues and just doesn't want certain issues to appear on the board for whatever reason, then he could use JQL to filter out the ones he doesn't want to see on the board.

If it's a case of something like remediating a security vulnerability, and you don't want the world to know your application is easily hackable, then that would be a good use case for issue level security with a Scrum board. 

[Brant Schroeder]

@Thayne Munson - I agree with many of the comments that have already been shared.  In my experience we have used issue security on smaller projects to hide sensitive issues and full projects on larger projects (where we have multiple project feed into a single board).  Both have worked well to secure issues when this is needed. 

[Aradhana Gupta]

Well, Agile provides a framework and asks us to be transparent.

Transparency comes at different levels. being transparent does not necessarily mean displaying all information to everyone.

Hence, in my opinion Security and Transparency should not be interchanged. Both are needed to have a successful and content team.

Coming to Private Boards, Yes.. they do make sense for a variety of reasons. Simply to not clutter a lot of boards or to manage my work my way.. :)

Well idealistic and realistic are like the horizon... a merge is an illusion :)