Ideally, before performing the Sprint Planning session as a team, the Product Backlog Items those will be potentially included in the next Sprint are supposed to be estimated in Story Points. The higher the priority of any Product Backlog Item, the higher is the expected maturity level of that particular PBI. Then, based on the average velocity data i.e. the average completed story points in the past, together with the expected capacity of the team for the next Sprint, the development team decides which PBIs should be included into the scope of the following Sprint. We, as the product owners are supposed to provide the right level of priorization and the overall direction to achieve a Sprint Goal before the planning session. This is basically how Sprint Planning works.
Nevertheless, Scrum teams may face scenarios where there may be strict deadline for a new feature or a solution. In other words, teams could face circumstances where the typical release planning could be not be applicable. To make it more concrete, let’s assume that the total amount of Story Points for a new to-be-developed solution is 100 SPs. Moreover, assuming that based on the proper planning done by PO according to the velocity of the team while preserving the projected capacity , it seems feasible that the team would require 4 Sprints in order to ship the solution. There are chances that, due to a certain reason ( Top Management expectation, natural deadlines such as Christmas, back-to-school season etc.) it may not be feasible to run 4 Sprints as the strict deadline does not allow such a period of time. Let’s imagine that for this example the deadline is just 3 Sprints away. Than the big question is how should a PO react if she/he encounters such a case ?
„How does it work in Scrum if there is a strict deadline ?“ weiterlesen
I’ve just finished reading the book called „Agile Product Management with Scrum“ by Roman Pichler. I had really enjoyed it. It provides valuable insight regarding not only about the Agile Product Management but also tips and tricks to become a great product owner.
At the last part of the book, there was a section that I found very interesting and insightful. It’s the following table that has been referenced to Lyssa Adkins, author of „Coaching Agile Teams“.
When I’ve came across this table, I’ve openly criticized myself and think about if I’m having attitudes of items in the „Don’t“ part. My sincere feedback to myself was there are times I might fail to „protect the team from outside noise“ and instead of „incorporating change between Sprints“ there are Sprints in which I allow change to jump in to. I thought I’m doing not bad at the other items. I’ve decided to ask openly to the development team their feedback by commenting for which item they think my overall attitude is on the „Do“ part and for which in the „Don’t“ part.
Generally speaking, they agreed with me regarding my improvement areas that I’ve found out by doing self-criticism. Almost all of them thought that it’s very positive and bold move that I’m asking their feedback in this way. On of my colleagues told that he is aware of the pressure I’m carrying on my shoulders and he is ready to support me as much as he can. It made me feel better that they are sensible to the challenge of my position and do empathize. What I’ve done later on upon receiving their feedback is I’m no longer including the development team to the email exchanges I’ve been doing with the shareholders in order to isolate them. Earlier I was keeping them in the loop so that we can be aligned as a whole team. Besides, I’m putting more effort not play to much with the SBL and keep the ground as stable as possible.
In a nutshell, as product owners we are the ones who are carrying the biggest responsibility to maximize the value delivered my the development team. As a result, we are the ones who are under fire most of time. In order to become great Product Owners we have to improve our expertise and acquire the know-how required for the domain while being kind, patient, empathetic, open-minded and also cool 🙂