Scrum: How should conversations with the product owner be logged?

Question

I've just read the Scrum Guide as I have no experience with scrum and my team is starting to use the methodology. We use JIRA to record/track our issues, but a common process is that we get operational questions/requests through email or in person. We add those to JIRA as operational tasks (we don't have a development and operational team, everyone does both) and make note of what was done. Usually have an email thread asking all the necessary questions, or if talking in person just figure it out there.

What if I am working on a sprint task and I have a question about a specification? My understanding is that enough requirements to get started should be established in sprint planning, but nothing beyond that. Further requirements should be discovered and provided in a just in time fashion. Does the developer reach out directly to the product owner for an answer or go through the scrum master? Should this conversation happen in JIRA through commenting on the related task, or should it happen via email? If email, should a summary of the correspondence be recorded in JIRA for the rest of the scrum team to see and prevent the same question/issue being repeated?

Answer 1

First and foremost, your process should be adapted to what you feel works best for you. Having said that, I think there are some general guidelines that might help:

• You should not involve the Scrum Master in the process of clarifying requirements with the PO. It introduces a dependency, and you might get blocked if he is busy. Furthermore, it makes your communication with the PO go through an extra layer, which is a recipe for misunderstandings.
• If you have tasks with very little detail, you will have to synchronize with your PO more often, which might become an impediment if he is not available enough. So you have to adjust that level accordingly.
• The communication works best when you have a quick feedback. So in person is better than chat, which is better than email. However, once you reach a conclusion, you should document it somehow in JIRA or somewhere else. Otherwise, other members of the team might not know what you discussed and may ask the same questions again. Also, that might be the only documentation you have regarding that particular decission.

Answer 2

You don't log any time with the product owner, and you don't go through the scrum master. That's a bunch of overhead that's simply not worth it. Remember the very first statement in the agile manifesto:

Individuals and interactions over processes and tools

Just go talk to the product owner. Conversations are part of software development process just like typing on the keyboard. If you don't log how many hours you type, you don't need to log how many hours you interact with others.

If you're a developer, make sure you include someone from QA in the conversation if it's more than just a quick question. And if you're in QA, bring along a developer.

After the conversation, make sure any decisions have been dissiminated. A short note in a JIRA ticket might be enough, or you might need more acceptance criteria. Or, maybe it's enough to just talk with your other teammates so that everyone is on the same page.

Answer 3

Employee body cam. Its the only way to be sure

Seriously though, If a dev has a question about a ticket, it should be raised in the daily scrum as an Impediment and answered by the Product Owner (who attends the scrum for this purpose)

If the PO isn't able to immediately resolve the question, "check document X23!", "oh that's wrong it should be Q" then they should follow up outside of the daily scrum.

If the answer is found, then the ticket should be updated with the information.

If the answer expands the scope of the ticket, the new scope should be put in the backlog, not the current sprint.

At least that's the Scrum answer.

Answer 4

Something I was surprised about when actually using Scrum as it is defined is the amount of formal activities there are. One of the items is called "Backlog Grooming", which is one of the places where you are supposed to mature the requirements with the customer.

The idea is that in backlog grooming, you are defining what it means to be done, and understanding what the customer really wants. You can do some initial cuts at estimating, but more than likely the stories in the backlog will have to be split into smaller stories--ones that can be done in 1-2 days. The net effect is that the items at the top of your backlog are better defined, and the items at the bottom of the backlog are just ideas.

"Sprint Planning" is where you actually decide which backlog items go into the next sprint. The customer is there for the first round to decide priority and answer any questions that are still there. In the next round, the customer is not present, but close by if there are specific questions that need to be asked. That lets developers get more technical.

---

One thing that Scrum does not handle well is the scenario where the same team is handling operations support as well as development. A closely related approach is called "Kanban" which works really well for operations.

The biggest difference in Kanban vs. Scrum is that there is no real "Sprint Planning" event. Backlog grooming still behaves like it does in Scrum, but the developers pull from the top of the backlog to get work done. That means backlog grooming also has to prioritize the backlog.

If you attempt to do a hybrid approach, then keep your sprints intentionally lean. You need to build in slack to handle high priority support tickets, but still get the work you signed up to do completed. If you finish the designated work, you pull from the top of the backlog items you can complete and demonstrate before the end of the sprint.