14

If you are following Scrum as defined in the Scrum Guide, the Product Owner cannot simply add stories to the Sprint Backlog. The Sprint Backlog, which is created as Sprint Planning as a negotiation between the Product Owner and Development Team while considering past performance and forecast capacity, is owned exclusively by the Development Team. If work ...


11

TL;DR There is a lot going on here. The short answer is that the Sprint Review does not have to be a demo but Scrum does advocate that the team should produce a potentially shippable product increment. That means the code is able to be shipped even if the Product Owner chooses to hold it back for whatever reason. Breaking Down Your Post Minor points ...


8

Choosing two answers, I would select A and D. B can be eliminated since project plans and formal change request procedures aren't typically a part of agile delivery approaches. Agile Software Development favors collaboration and responding to change over long-term plans. Frequent delivery of working software and responding to change builds a change request ...


6

Demonstrations are Required; Visual Demos are a Best Practice Scrum requires that work be demonstrated during the Sprint Review. The Scrum Guide says: The Development Team demonstrates the work that it has "Done" and answers questions about the Increment[.] While the framework doesn't require hands-on or visual demonstrations, it's widely considered a ...


5

First off, +1 for checking the Scrum Guide! The book answer would be that it says the attendees include The Scrum Team and with no extra qualifiers, it can be assumed that it means the whole scrum team (Dev team, PO, SM). But I'd hate to just give you the book answer, so in my time practicing Scrum, here are some of the benefits I've seen to including ...


4

TL;DR You say that some teams believe the following: [E]very story must be complete by the end of the sprint. It may be true that some teams believe this common misconception, but it's factually incorrect. The Scrum framework requires that the Scrum Team must do its best to deliver a coherent Sprint Goal each Sprint. User stories (or, more canonically, ...


4

Yes! My recommendation would actually be to have a really small goal that is easy to see, but doesn't add much work (or maybe value). It's more of a talking piece than anything. That first review is a great time to set the stage for the project and get people introduced. You don't have to fill the time box, but it's a great no-stress way to start things off ...


4

Forget about Demo. Before downvotes start to fly, bear with me. As Venture mentioned (+1!), you have foundation problems that should be addressed before you get concerned about a Demo. I'll bet you come from a Company where senior management heard that Scrum is the next big thing and you should be having Sprints and Demos and Daily meetings to grab a few ...


4

Discussing problems during Daily Scrum is perfectly fine. When a team member mentions some impediment you can stay right after the Daily Scrum and discuss the issues. From Scrum Guide: Here is an example of what might be used (during Daily Scrum): ... Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal? The ...


3

I think it's generally true that the emphasis of the Sprint Review is on the product and the Sprint Retrospective is on the process, but that doesn't mean the Sprint Review is exclusively about the product and the Sprint Retrospective is solely about the process. The Scrum Guide does state that during the Sprint Review, "the Development Team discusses what ...


3

As you suspect the standard purpose of the scrum review is to 'inspect the Increment and adapt the Product Backlog if needed'. In practice this means showing what work is now done (so these items can be removed from the backlog) but also to review that any changes in the market conditions & use cases of the product haven't caused a change in priority or ...


3

You need to review the product increment. From what I understand from your question, it seems to me that you are mostly reviewing the work that you did to build the actual increment. If you want to track the work, acceptance testing or integration testing should be tasks associated with a User Story. You might also have a task for development, for code ...


3

tl;dr; There is no "right" answer. Whatever works for your team and client. Probably Not a Bug Sprint feedback is rarely a bug. While there is no strict definition, a bug, or defect, is a term usually reserved for when an application does something that everyone knew it shouldn't (or vice versa). So unless demonstrating the feature happened to turn up a ...


3

TL;DR You may have an X/Y problem. While failure to achieve the Sprint Goal is a problem if it happens often enough, the actual issue you're facing seems to be a lack of trust in the Scrum Team. This is often the result of a lack of process transparency and poor (or at least delayed) ongoing communications with your leadership and/or stakeholders. The ...


3

architectural user stories with no business value I encourage teams to create a very simple 'hello world' style first user story that offers limited but non-zero business value. Then do all the technical setup tasks under that user story. The benefit of this approach is that it gets the team in to the mindset of always focusing on the delivery of business ...


2

TL;DR Scrum requires that the event be held at the end of each iteration, even at the beginning of a project. While you might consider shortening it, or shifting the focus slightly towards process rather than deliverables, the event should still be held. Events Build Cadence Formally, the Sprint Review is a required event in Scrum. While it's certainly ...


2

Seconding the recommendation not to do this at the sprint review. I think you have a bit of coaching to do with all involved parties as to the purpose of the sprint review. After that, I would ask Dev Manager and Director would be, why do they want to know these things? What are they going to do with the information? I would also coach the scrum team (...


2

Problems or things which went wrong, should be raised in the retrospective. The retrospective is for the whole team internally. The results can be shared with others. The retro is the event with the green (what went well) and red cards (space for improvement). Inside a retro the are no hirachy, many teams exclude management from that meetings, so everybody ...


2

There isn't a straightforward answer to this type of question because a lot depends on: the nature of the problem. Is this a technical problem? Is it a product related problem? A problem regarding the processes, practices or tools? Is it about the team? the target audience. Who needs to know about this problem, and most importantly who needs to solve it? ...


1

When to talk the problems we encountered during sprint, Sprint review or Sprint Retrospective? When it's more effective. Scrum (and agile) are not very prescriptive. That's one of the biggest challenges for people trying to shift into them. and that's good. Just requires experimentation. The same challenges can (and will) be raised at different forums, ...


1

In the Sprint Review, you show the customers (and everyone else that is interested) the product increment you have just completed. If during the sprint you encountered problems that caused you to deliver something else than what you lead them to believe (less functionality, different functionality, etc.), then it would be good to mention those problems as an ...


1

A few things to consider: First, let's start with the best: you have super-engaged stakeholders. That is so awesome! And nothing in Scrum says you have to wait until the end of the sprint to show completed work to stakeholders. I don't think it can be overstated how wonderful it is that your team and stakeholders talk frequently! Personally, I wouldn't do ...


1

I would give the following comments to your practice. Daily Scrum: The daily Scrum is a meeting for the team members to discuss if it is possible to reach the sprint goal. In my opinion, there is no space for Stakeholders to review certain user stories. Sprint Review: I wouldn't cancel the meeting. Referred to the Scrum Guide, demo the user stories, ...


1

is the 20 old stories represent a release? if yes there is a real problem at the business vision, where that the 20+ stories will completely lead to another product and how these extra stories were added it should be a collaborative process (PO with team), you have to re-estimate the stories, re-planning the release and the iteration, some people make the ...


Only top voted, non community-wiki answers of a minimum length are eligible