1

I am a developer. A backlog jira is assigned to me for grooming. The jira contains a short description of the requirement and also the acceptance criteria. Also a problematic sentence as below, which points to a document.

"Find additional information in the specification document located in the following link --"

My scrum lead raised a concern that this way the requirement could get modified at a later stage if the JIRA is pointing to a document. According to him, the complete requirement should be defined in the JIRA itself. So he wants me to ask the same to my Product Owner/Architecture team to confirm the same over comments on the JIRA. Now the document itself is 50 pages long and cannot be fully posted on the JIRA.

How do I politely ask over comments on JIRA to not point the requirement to a document attached on a URL. The PO is a very senior guy and I want to ask this in a diplomatic way.

|improve this question
  • 3
    If this is an impediment, it's the scrum master's job to move it out of the way. In general, it's not always possible to have complete specifications in a ticket system, but if external document repositories are used, they should be stable (i.e. it should be obvious which versions exist, and which version was the one the team committed to). – Hans-Martin Mosner Aug 27 at 10:27
  • 2
    Is there any chance that someone (new team member, customer, etc.?) has access to the JIRA project, but not to the URL with the document? If so, you could use that as an argument for attaching the document to the JIRA ticket instead of linking to an URL. – Bart van Ingen Schenau Aug 27 at 11:01
  • 1
    Is the information in the document required to fully understand and work on the item recorded in Jira or is it more informational? I'd agree that the ticket should be self contained, but there are definitely reasons for traceability to link a ticket in a tool to outside documentation. With Jira, especially, if you are also using Confluence, you get interesting integrations that can add stakeholder value – Thomas Owens Aug 27 at 12:04
  • 2
    "My scrum lead raised a concern that this way the requirement could get modified at a later stage if the JIRA is pointing to a document." Why not just use version tracking on the documents? (You yourself said that you cannot enter 50 pages into JIRA) – Danny Schoemann Aug 27 at 13:12
  • I think the actual issue here is the Scrum Master's reluctance to communicate with the Product Owner, and wants a developer to do it for him via a JIRA comment. Sounds like team communication issues. You should be reviewing and refining your processes in sprint retrospectives, as a team. – BadHorsie Sep 5 at 12:01
2

It seems as your scrum master both sees the problem and is suggesting a solution on how you can handle it. If the scrum master knows about this concern and what problems it can cause, he/she should bring it up to the product owner immediately. Especially if you as a team member are not comfortable or you need help talking about this with the product owner, then it's up to the scrum master to help you.

When I read your question it seems like a lot of people see this and knows about the problem, but there is no communication with the product owner about it. If I were the scrum master for this team, I would arrange a face to face meeting where you talk about this in the team and come up with an action on how to solve it together.

The product owner is a part of the team just as much as the developers and the scrum master. It would be in the product owner's best interest to solve this together with you. Remember that when working in a team there should be a safe environment for you all to share your thoughts and concerns directly with everybody involved, regardless of role or experience.

I would recommend that the scrum master facilitates a retrospective on this subject. This is a great way to let everybody share their thoughts and come up with actions on how to solve the problem.

|improve this answer
2

This is what retrospectives are for.

  • Inspect how the last Sprint went with regards to people, relationships, process, and tools;
  • Identify and order the major items that went well and potential improvements; and,
  • Create a plan for implementing improvements to the way the Scrum Team does its work.

You have a process problem here. Your PO is using one way of doing things. The developers think another way is better. So bring it up at the retrospective and discuss ways to improve the process. The Scrum Master should facilitate the discussion. In a proper Scrum team that should be all of it, however, from your question I sense a few things that are not quite right.

First of all there is a communication issue. Communication should be open among team members but somehow you seem reluctant to bring this up to the PO's attention.

Next, is a lack of transparency and maybe trust. You think that the external document might be changed without anyone knowing and things might go out of sync (e.g. functionality vs requirements). This might occur by mistake, in which case it's a transparency issue. The artifacts are not completely transparent (for example, who has changed what, when, and why. And if the change was already implemented in the application or not). So this introduces risk. If you are worried that the documents will be changed intentionally then you have a trust issue which introduces even more risk.

Either way, you have to bring this issue up. Make a decision together, and agree on a solution to everyone's liking. Some sort of versioning in Jira/Confluence might be the way to go.

|improve this answer
0

Product Owner should collaborate with the team and, in my experience, first and foremost clarify scope for a sprint.

One example of scope creep ( and madness, even for PO!) it's an issue with a huge document attached.

Scrum master should help PO to clarify and organize first sprint's scope, then issues following S.M.A.R.T. requirements and keep documents as reference for validation.

Note: I was PO for a year, define an issue is an hard (and alone) task. PO should be helped in find time to work on this, define every issue for next two sprints, never for today work, so there is time to think and refine work. Use grooming with team (and even scrum master) is a plus, to understand if an issue is defined correctly. I also attached documents to jira's issues sometime, but as reference for team, if during estimation more information are needed for broad context.

For this, maybe a wiki should be used, to collect these "contextual" information and help also new team members

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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