Sprint Review and Done Increment
When inspecting the Product Increment in Sprint Review is this Increment already a Done increment or is there a discussion to check whether it is Done? In my opinion the Scrum Team should collaborate during Sprint and present a Done increment in Sprint Review. New insights should result in an adapted backlog. Any discussions if the Increment is Done (e.g. meeting expected scope or quality criteria) are not part of the Sprint Review since this increment is Done per definition.
I've seen Scrum implementations where the Product Owner gives an approval in Sprint Review whether the increment is Done and I am asking if this a good habit. Do you think it makes sense to add this approval mentioned before to the teams Definition of Done?
The Product Backlog should show how much work remains to be Done. At the end of a Sprint, any undone work should be re-estimated on the Product Backlog.
If a Product Owner's approval was included as part of a Definition of Done, how would the Development Team estimate the work needed for this approval? Is it something which reasonably lies under their control, just as other development work ought to lie under their control?
If any of the work required to achieve Done lies outside of a Development Team's control, should they really agree to do that work in the first place, and commit to any goal that depends upon it?
PO may suggest to add to the DoD, but DoD need not contain PO's approval to check an increment as done. If PO is not available, and Dev Team has completed their activities (including testing) - they need not wait for PO's approval to mark it DONE. It is better for both the Dev Team and PO to be aware of ongoing sprint, which is more than sufficient.
The Sprint Review is for all the stakeholders (not just PO) - and in these reviews PO is virtually a part of Dev Team, since (s)he is also responsible for the delivery. And yes, as you mentioned - only items that are DONE - will be presented in the sprint review. If something is 99% done, and only 1% work is remaining - it is still NOT DONE, and it has to be added back to the PB and re-estimated during next sprint.
@Adwait:
PO may suggest to add to the DoD, but DoD need not contain PO's approval to check an increment as done.
Why do you believe it is not necessary for a Definition of Done to contain PO approval? Why would you propose that items can be presented in a Sprint Review without being reviewed (and approved) by the Product Owner?
If PO is not available, and Dev Team has completed their activities (including testing) - they need not wait for PO's approval to mark it DONE.
Product Owner unavailability is indeed an issue, but it is a poor reason to then rely solely on the Development Team to mark an item as Done.
in these reviews PO is virtually a part of Dev Team, since (s)he is also responsible for the delivery.
This is incorrect. The PO is 1/3 of the Scrum Team (along with the Development Team and the Scrum Master), and the PO is not responsible for delivery (the Development Team is, per the Scrum Guide). Among PO responsibilities is to optimize value through Development Team deliverables.
If something is 99% done, and only 1% work is remaining - it is still NOT DONE, and it has to be added back to the PB and re-estimated during next sprint.
While it is true that incomplete sprint items should be placed back into the Product Backlog and re-estimated, I would suggest that there may be other ways to manage items that are actually 99% completed, instead of a hard and fast rule to declare them incomplete and kick them back to the backlog.
In Scrum, items are either Done, or Not Done. It is actually wasteful (Lean) to measure % completion of items within a sprint. That said, if 1% of an item remained to be finished (perhaps a small defect?), it is possible that 1% could be negotiated with the PO, and either set aside by the PO as unnecessary, or carved out into it's own item so that the remaining 99% may be approved by the PO.
How can I explain to our Scrum Master that a Sprint Review Sessions should not "show" incomplete work?? Is it correct during a Sprint Review, items by definition "Done" should be "shown", and anything not finished / incomplete should be placed in the backlog? Our team's definition of "Done" is when it goes through IAT (Internal Acceptance Testing). a potentially shippable product... I'm not sure why our Scrum Master doesn't understand this since he's a certified Scrum Master..? Do you have any suggestions on how I can get this point across?
Thank you-
Might it be useful, during a Sprint Review, to have transparency over work started but not completed? What does the Scrum Guide say about work which has been "Done", and work which has not been "Done"?
Hello, what comes first? increment or sprint review? I think it is increment but graphic on www.scrum.org/resources/what-is-scrum is misleading as it shows the increment as an output of sprint review.
Thanks for your help.
Hello, what comes first? increment or sprint review? I think it is increment but graphic on www.scrum.org/resources/what-is-scrum is misleading as it shows the increment as an output of sprint review.
Thanks for your help.
The Scrum Guide says "A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed." So I would consider it wasteful if people join a Sprint Review and there is no Increment ready to be inspected.
The Scrum Guide doesn't refer to adapting the Increment during the Sprint Review. Indeed for most teams, that would be an inefficient use of the Sprint Review, and may result in a loss of focus; but there is nothing in the Scrum Guide to say that it cannot take place, and that a subsequent Increment cannot be produced before the end of the Sprint.
Furthermore, it's fairly common for work to be Done, and even released throughout the Sprint. In such a case, it is often valuable to inspect both the released and unreleased parts of the Increment.
what comes first? increment or sprint review?
The decision to release an increment ought to be as timely as possible. The Sprint Review is an opportunity to inspect the very latest market or business conditions at the end of the Sprint time-box, and a just-in-time decision to release the very latest increment can then be made.
Hello Team,
I'm recently started an Assignment as Agile BA .
It would be great if anyone can describe the Documentation and the process involved in Agile Scrum methodology in BA perspective. I'm confused on the documentation, few say, BRDs also have to be documented apart from writing User stories. Can anyone take few minutes and explain on the same.
Thanks
Kartheek
Can anyone please suggest me the documentation required for a BA in Agile Scrum Project.
Appreciate your help.
Do you have reason to believe that any particular documentation will be required at all?
What information do the team actually need in order to refine the Product Backlog?
Hello Ian,
Can you please explain BA role in Agile Scrum Project.
What are the different documents developed/written by BA like Epic, User stories etc., Is there any other document required which describes the flow charts or the configuration/integration. Some people say, though its Agile, we have to prepare BRDs. Here am confused.
Would request you to share your valuable inputs.
Thanks
Kartheek
@QA Wiz
How can I explain to our Scrum Master that a Sprint Review Sessions should not "show" incomplete work?? Is it correct during a Sprint Review, items by definition "Done" should be "shown", and anything not finished / incomplete should be placed in the backlog? Our team's definition of "Done" is when it goes through IAT (Internal Acceptance Testing). a potentially shippable product... I'm not sure why our Scrum Master doesn't understand this since he's a certified Scrum Master..? Do you have any suggestions on how I can get this point across?
Not sure what your role is in the team, but that shouldn't matter. Instead of explaining to your Scrum Master, perhaps you could go through the Scrum Guide together and come to a common understanding of what should and what shouldn't be. Taking into consideration the context of your team.
One thing I've learned is that certification does not make the Scrum Master. Experience and a whole lot of feedback are required.
Kartheek,
What documentation (if any) does the Development Team require before they feel comfortable accepting an item into a sprint?
The Scrum Guide does not prescribe any level of documentation:
Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. The Scrum Team (Development Team, Product Owner, Scrum Master) decide how and when refinement is done.
One thing I will say, based on my many years of experience as a Scrum Master, is that I have yet to meet a Scrum Team that creates a BDD before beginning work on an item. BDDs are part of the "Big Design Up Front" approach popular with many traditional project methodologies (i.e. - waterfall). Agile/Scrum has little if anything to do with big design up front.
Can anyone please suggest me the documentation required for a BA in Agile Scrum Project.
There is none. Your organization might have its own rules, but Scrum Guide does not mention BA at all. I could however imagine such person helping the whole Scrum Team define and understand future tasks, preferably by adding details to Product Backlog Items...
Hi There,
As I understand the Sprint review is to showcase the Increment to the stakeholders. The doubt i have is whether the increment is given to the PO before or after the Sprint review.
Thanks,
VB
Are you familiar with theits meaning and purpose?
The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints
The increment in itself is never "given" to the PO.
Do you have a definition of done in place? What does it say?
Do you use a TDD approach? Automated tests? Etc...
Depending on each team's particular circumstances (cause all teams and setups are different, and therefore unique), the PO may or may not need to review each individual ticket / story. In setups where there are tens of releases per week (CI/CD), the PO would surely not review every single item.
... whether the increment is given to the PO ...
Where in the Scrum Guide does it say that the increment is "given" to anyone? The Scrum Guide says that the product of a Sprint is a potentially releasable increment of work and that the PO has the decision on whether to release. Read this section.
https://www.scrumguides.org/scrum-guide.html#artifacts-increment
There are multiple places in the Guide that mention the Product Owner's decision on whether to release the Sprint increment.
My opinion is that if the PO is seeing the increment for the first time at the Review, the team is not doing a good job of transparency and communication. It makes the Product Owner's decision on whether to release much more difficult if they have to reach that decision within the confines of the Sprint Review. They should have as much time as possible to make such an important decision.