In an effort to get more ideas out I am going to share some briefer thoughts and half-formed concepts I am working on. Here is one of those.
When a team plans their work for a sprint, there are three over-arching questions that should be considered:
- What business value are we adding this sprint? No matter the work being done successful Agile sprints are always about adding business value and so the team should be able to articulate how their work that sprint will advance the product or program toward achieving key business objectives.
- What are we trying to learn this sprint? Part of the value of an Agile mindset is the freedom it encourages to keep learning, experimenting, innovating, and growing. We don’t start with all the answers and then just build the thing that solves every problem; we attempt to add the next thin slice of value for our users and see what we can learn about how else to enable their success.
- What success criteria will we use to determine how effectively we’ve done these things? In pursuit of continual improvement, the team should always be able to state how they can tell if their work is heading in the right direction; clearly defined success criteria allow the team to plan upfront how they will measure the effectiveness of their learning and development efforts. As they evaluate their success and learn from their mistakes they can continue to hone their work going forward.
These questions provide the context for whatever work gets done and ensure that the team is focused more on the outcomes they are pursuing than on the simple output of the sprint. Keeping these questions top of mind when planning doesn’t guarantee that all goes well of course because in truth it’s not that simple.
Wow!! Great talking points. Here are mine:
1. What is role of a po (product owner).
2. Who’s responsibility is it to come up with list of dependencies for an end to end delivery?
3. Does PO alone has to slove those dependencies or he can delegate back to pod once he identifies who are stakeholders the pod requires to work with to resolve those dependencies
4. Are po literally required to tell each pod member what story they have to work on? ( in my thoughts po prioritize the workload that has highest business value, establish acceptance criteria for the workload and then its the pod members who have to breakdown/decompose the workload into stories and define the acceptance criteria that is aligned with the workload acceptance criteria.