Fairly new - Confused by cancel, delete, goals
Hi,
Our company is fairly new to moving to Agile development and we are using the popular Scrum approach. I'm fairly new in the role of Product Owner and the team is Scrum team is new equally to the the framework and so is the Scrum Master. So yes a lot of newbies. We though have a Agile Coach that works across the entire company that provides some guidance, sometimes a bit light due to the fact there is only one of him available for about 8 teams moving Agile.
Anyway - I have read a lot of documentations about Agile & Scrum overall and the responsibilities of the 3 roles (PO, SM, Team) but as we embark in the journey we had a couple of scenarios where we were unsure what should have happened and whether the following strictly a guide is hindering our agility (irony!)
So I would like some guidance into the following scenarios how to best approach them and understand the roles of each:
1) We run refinement/grooming sessions (about 1h twice a week) in order to run through each items of the product backlog with the attempt to cover over 2 weeks (which is also our sprint duration) about 2 sprints worth of work (first week focus on getting enough items ready for next sprint planning and the week after for sprint planning after next). When starting the workshop the Team has in the past refused to discuss a product backlog item because it did not have the entire exhaustive list of acceptance criteria.
As a product owner I would talk through the item which would typically have a user stories in the form of I as [user], I want to [action], so that [value/achievement] and a plain english description e.g. Build a table row that shows the membership price paid and its frequency.
And often the set of Acceptance Criteria using Gherkin (Given a user logged in to their member area AND with a monthly membership fee WHEN viewing their member price THEN the price is show $XX.XX AND the frequency "monthly" is show on the right of the price etc.) is ready. But I may have missed a case which I'm expecting we could uncover during the refinement as a team.
Am I right to think that during refinement/Grooming as a team we can work through a number of items that have more or less details (as long as a story is articulated) and use that time to brainstorm those acceptance criteria, whether the story is small enough or too small and whether the value is well articulated? Or is the expectation that when gathering the team to review the PBI they are fully "ready"?
2) This other scenario is about what happens within a Sprint - Let's say the Scrum team have committed to say 40 story points and completing the selected PBIs will achieve the sprint goals of - "Membership information exhaustively displayed and Membership interaction fully tracked within the analytics suite" (and next sprint would focus on timetable display for example).
On Day 2 of the sprints as each team grab a story to work on, one of the developer is working on a story that says "As a UX Specialist, I want to track tooltip closure actions, so that I can analyse how customers close a tooltip and how often they use each type of action" - the developer realises through his initial investigation that there are 3 ways of tracking the interaction of closing a tooltip and the acceptance criteria only recorded 2 actions (e.g. close on clicking a cross / and clicking the "close" button and we can also track tooltip closed by clicking outside the window).
They discuss with me their finding and advice that they are still able to achieve the story goal & sprint goal and include the 3rd action. We then include this 3rd acceptance criteria to validate the story. The team though believe it is not the right agile/scrum approach and that no items within the sprint backlog should ever change and all acceptance criteria should be fully locked before entering the sprint - they then decide as a scrum team without PO negotiation to remove the acceptance criteria and request me (PO) to create a new story for this acceptance criteria that will need to be prioritised and brought into another sprint. They also advised that they thought about cancelling the sprint but did not as we are already behind in terms of the release plan.
As a result the sprint goal of completing the membership section won't be fully complete as this component has been missed. What should have been the right approach? Is is acceptable that some acceptance criteria might be uncovered during the sprint as long as it does not change the meaning of the story? How much can be discovered and accepted during a sprint? Is it the Scrum team decision to remove ACs or add ACs within the sprint? What's the right process? and same question regarding cancelling a sprint? Is is the team decision to cancel a sprint? I'm a little confused here.
I would have thought that entering a sprint there might still be a % of AC that might discovered as a we go through the investigation and don't necessarily know every single rules that sometimes require collaborative effort to understand?
3) Similar to above through the sprint we discovered that we missed a business rule as a result 4 AC had not been documented and conditioned the display of an action button. What should be do? And should be take into account circumstances? for example if the developer took the initiative as part of his investigation to implement the missing business rule (so basically the work is already done) - should we still remove the story entirely from the sprint missing the goal?
4) Last question being if we realise 2 days before the end of a sprint that part of a story is complete but the other part is not clear enough in the sense that it is missing specific acceptance criteria - should we mark the story as "done" and create a new one that cover more precisely the AC or should be refine the story during the sprint and provide the AC in order to be able to complete it?
[With better refinement session I believe we can reduce these instances but trying to understand how we should tackle those cases and understand the involvement of the PO in those decisions]
Sorry for all the questions - I have ready quite a lot of different documentations but I find that the most learnings are in specific scenarios that we don't always find an answer to and there is probably not only one answer possible :-)
Thank :-)
During Product Backlog refinement, the Product Owner and Development Team should collaborate on making upcoming Product Backlog items ready for Sprint Planning. They will add or improve descriptions, order, detail, and estimates. Items on the backlog may exist at different levels of granularity at different times.
A team that commits to points rather than towards meeting a Sprint Goal may not provide the best value. Value can be expected to lie in the increment they hope to release, rather than in story points.
The Sprint Backlog is a plan or forecast of the work which the Development Team think is needed to meet the Sprint Goal which has been agreed. That plan or forecast is subject to change throughout the Sprint as new things are learned. For example if the team believe they have found a better way to achieve the Sprint Goal, or the need to overcome an unforeseen impediment towards achieving it, then the Sprint Backlog ought to be updated accordingly. This may include revising backlog items, such as user stories, so that a better plan for meeting the Goal can be followed.
1) Your observation is correct - the Development Team and the Product Owner should collaborate continuously around PBI refinement. While some refinement may be done outside of this approach (i.e. - PO alone, SME/architect separately, etc.), there should not be any expectations set on PBI thoroughness (all AC accounted for, for example) prior to refinement discussion between the Dev Team and PO.
2) Only the PO can cancel a sprint, and that is an extreme case only (i.e. - Sprint Goal is suddenly no longer valid). As Ian stated, the Sprint Backlog is not static, and may evolve throughout the sprint as more is learned. The Development Team is incorrect in believing that scope is somehow locked down once the sprint time box begins.
3) Along with #2, it may be a better approach in the future when AC or business rules are found to be missing, to bring such observations to the entire team for discussion. Ask the team how they would like to manage the situation, keeping the goal of delivering quality product foremost in their minds. A seasoned Scrum Master or Agile Coach should be able to help guide such discussions.
4) A story is either complete, or it isn't. It isn't an option to split the "done" part from the"unclear" part of a story. The story should be de-scoped from the sprint (assuming it can't be finished according to DoD), put back in the backlog, refined, re-estimated (remaining work only), and reintroduced into a future sprint at the PO's discretion.