*HELP* Not quite clear about the Sprint development!

What do the Developers have to say? Do they understand the value of transparency and offering transparency to key stakeholders? If so, how do they think that they can best offer transparency to those key stakeholders? One option would be updating Jira and ensuring that the stakeholders can view the state of work in Jira, but that's not the only way to allow stakeholders to have visibility into progress toward the Sprint Goal.

I'd also want to dig into what's happening at the Daily Scrum. Are the Developers reflecting on their progress toward the Sprint Goal and planning their day to maximize the chances of achieving their Sprint Goal at their Daily Scrum? If they have concerns about their ability to meet the goal, are they raising those concerns to you, as the Product Owner, to help make decisions about how to optimize for the value that can be delivered?

It should never be a surprise if the Sprint Goal was achieved or not. Between the Daily Scrum being used to identify any risks or impediments to success and raising those to the appropriate people or transparency into the state of the work, at the very least, key stakeholders should always have insight into the team's status and progress.

We do not have a Scrum Master at the moment.

The problem you have described is exposing the consequences of this. Nobody is accountable for people's understanding of Scrum or for its effective implementation. That's the issue which needs to be resolved.

Bear in mind that as PO you are accountable for all of the investments being made in a product over its lifetime, including the money spent on the current Sprint. If you are unsatisfied regarding Sprint Goal viability, considering  that no-one is accountable for Scrum's implementation, you'd be within your rights to cancel it.

Having a Scrum Master would solve the problem of facilitating daily scrum and retrospective events. Which would ultimately be helpful to have the transparency on the progress the scrum team is making. 

Also during retro, it should be clearly discussed on the gaps w.r.t to the Jira board updates not happening regularly. 

If, there is no possibility of a Scrum Master to be placed, we can advise one member each week to take care of these updates and ensuring Jira is updated all the time and rotate the responsibility of the work among the team members each week. 

If nothing is working out as planned above, cancelling the sprint would be the final take as the Product Owner. 

Thank you @Ian @Kiran and @Thomas

Hello Rafael,

Have you talked with the team about this? What do they tell you? Maybe they as a team do know the status... (I doubt if they don't have a means to show it)... Does the team understand why you want this transparency?

Quite some questions... What I would start with is to make sure the team members understand the reasons for bringing this transparency.
Without it, they themselves cannot do decent inspections during their Daily Scrum. They cannot effectively indicate blockers, risks, etc. They cannot inform you as PO if they need to adjust and need input from you what to drop/change/add, ... In summary, they run a high risk of not reaching their Sprint Goal in a Done Increment if they do not make transparent what their progress is towards the Sprint Goal.
Not sure what the better tool would be in your context, but my experience is that Jira is more a pain than a help. I prefer with the teams I coach a highly visible, highly accessible, and highly collaborative tool - e.g. Mural or Miro digital boards (of even better, a physical whiteboard when the team works together in-person).

Hope this helps.
Grtz
Steven

"Transparency" is key pillar for any scrum team to be effective and it should not be you asking and they giving. The developers should be made understand it is not a status metrics and why they think updating the progress is not important ?. How to make them understand ? Well it is not by a presentation or just telling them will change things. but they would need coaching. Either you wear a coaching hat or you have someone to coach the team is depends on your situation.

Hi Rafael,

Through retrospectives, try to understand the reasons behind their reluctance. 

I have had similar experience with a team in the past. Team was fairly new to scrum and did not understand the importance of "time-boxing the work" & transparency. Coaching them about scrum definitely helped.

However, as per my experience, not being proactive would have some other reasons as well. 

1. Their work experience background & current organizational setting.
2. If they are not opening up in retrospectives about these issues, then try out anonymous feedback method during the sessions.
3. Keep a keen eye if they have any suggestions. If possible, pick them up. They will feel valued and will be more vocal about the issues afterwards.
4. Team bonding could be improved with you as a team member (& not just as a PO). They need to learn to trust each other & respect own commitments.
5. Lack of motivation to follow scrum processes.
    My team had problem of slicing the stories & they were not able to complete the work within sprint. That actually demotivated them further & they felt the process as overhead. You can try finding out if your team also feels demotivated, & if yes, why..
6. People do not like processes when they fail to see the (long-term or short term) benefits of using them.

I hope this perspective helps you.

Best Regards,
Tejashree.

P.S. : It is going to take more than few weeks to fix the issues :)