Subjects and outcomes of a sprint goal
Hi there,
I convinced my team that it was fair game to have information/knowledge as part of a sprint goal. However, I am struggling to find anything to back up my statement. Am I off in this case?
I am the PO and I want to get started on and tackle some of our most critical and riskier part of the product as i still holds quite some uncertainty and that I as I PO don't want to be the one trying to understand all the technical aspects and be the middle man trying to sort out technical dependencies.
In this particular case we were talking about a using a internal produced Global User Management System to enable differentiated user access However, the team was not willing to commit to a goal about integrating the GUM solution, as they at this point don't have the needed knowledge about how to do it and was not sure whether our internal service team had/could finish an API the team needed for it. I then told them, it would be fine to commit to a goal about gaining the need knowledge and ensure agreement in regards to dependencies to start GUM integration. The work won't take up all their capacity in the sprint and there will probably be some waiting in regards getting another team into a dependency meeting and get them to teach my team about GUM. Therefore, they also pulled in some lower priority PBIs they could get to DOD.
Anyone who could provide some feedback or good advice?
I am primarily interested in:
1. Can a goal be around knowledge? .
1.1 If not how can we handle a situation where the dev team don't want to commit to an actual increment due to lack of knowledge or certainty?
2. Is it fair game for me as a PO to push the responsibility of sorting out dependencies and details best solution?
2.1 Sometimes the dependencies is merely seeking out information about how to use something another team has created or to understand the technical possibility space. I often find myself in technical meetings and workshops about how internal services can/should be used and then have to be s middle man communicating that to the technical members of the dev team. Could I not ask them to have that as part of their sprint/PBIs.
2.1.1 if so, how can this be handled as a sprint goal as it rightfully might be difficult to commit to any increment without understanding the scope and how to?
Thanks in advance :)
Scrum is about learning to build the right thing at the right time. The purpose of a Sprint is to enable validated learning under complex conditions of high uncertainty, and a good Sprint Goal can be expected to align Developers to this endeavor. The knowledge so gained ought to be validated empirically by means of Done increments, each of immediately usable quality, each and every Sprint.
The situation you describe suggests that work is not ready for Sprint Planning, and hence commitments of this nature cannot be made by the Developers. My advice therefore is to improve Product Backlog refinement, so they have enough detail to know the work can be Done, including any dependencies which need to be managed.
Hi Ian,
Thanks for your feedback.
I would you in this case then have created a sprint goal with lower priority an lower value PBIs that was ready/refinet. Then during that sprint ensured that there is capacity enough left to help sort out the dependencies?
If so, couldn't that potentially compromise the goal, as now we would have a official sprint goal to make a lesser value increment but behind the scene the important thing is to refine and sort out the dependencies so we can get started on the absolutely most critical and value creating items?
My advice would be to ensure that the Product Backlog is adequately refined in the first place. If it isn't, then it may be wise to hold a time-boxed activity for that purpose.
It is important to enter Sprint Planning with a clear Product Goal, and enough ready work to frame and achieve a meaningful Sprint Goal which helps achieve it.
Backlog refinement is not an official Scrum event. And it is not the responsibility of any single individual. It is an ongoing activity that everyone on the team takes part in as it is needed. The responsibility of getting backlog items into a state that they are ready to be included into a Sprint is shared by everyone. This is why you should never try to plan a Sprint where everyone is "fully utilized". There is always some kind of work needed to prepare the Product Backlog. In the case you described, what I would have recommended as a Scrum Master is that the issues remain in the Product Backlog and more time is spent by the Developers to discover and refine the information needed. You could also spend more time working with the other Product Owners to work out prioritization of dependencies. There will always be discoveries made during a Sprint that could impact the work but there should be a plan in place for how to do the work before you start. The Scrum Guide states that "
The Sprint Goal, the Product Backlog items selected for the Sprint, plus the plan for delivering them are together referred to as the Sprint Backlog.
No one should be "pushed" to do anything. They should be willing to do what is needed when it is needed. If the Developers are saying that an item is not ready to be pulled into a Sprint, then it isn't. But it also means that those same Developers need to be spending time on that item to help make it ready and can not expect others to do all of that work.
Thanks Ian and Daniel for feedback and advice. I think there is something I can use here to improve my role and take back to the team :)