In our team, at the end of the sprint, the developers demo what they worked on. Do you think QAs should also demo what they worked on? In my case, it does not make sense because I do not work at the team and sprint level but at the department level. If anyone of you already does the regular demos as a QA after every sprint. Can you please share what you usually demo?
3 Likes
Hi @deepakcb,
People over Process. Donāt get hung up in āshouldā. What provides value in your situation and your team. 
If your work is more department/ feature level perhaps another sharing setting is relevant. I mean surely devs would like to know the department level :).
Though if you and the devs have the same manager share away - perhaps the demo is more about sharing the work within the team? Who picks up your work when you are away?
Sometimes the dev demo to those who test, and then the customer demo was done by the person who tested the stories. And thus those who tested are not part of the end of sprint demo.
Hope this helps - even ifās not an exact science 
5 Likes
Typically the devs and I have worked on the same therefore it does not matter that much who shows something. Sometimes as tester Iām more used to a user perspective, who the product is used, while devs focus often more on the technical aspects.
Devs makes the feature, I test the feature. We work on the same feature (,bug, backlog item, etc.)ā
3 Likes
I think it is up to the team, and ultimately depends on the comfort level.
I have demoed at the team level and also at the department level. Oftentimes, I have everything setup already so it was relatively easy to run through the demo.
Obviously, the dev should be present since there might be in-depth technical questions for them.
2 Likes
I typically demo releases to our User Acceptance Testing team, which isnāt every sprint with my team.
I cover new features, improvements, and bug fixes and then discuss upcoming work in the next sprint.
I currently QA for a VR application and frequently test not only the software, but the hardware and content components. We have several of what might be called product owners, and it can be challenging to keep everyone on the same page (the content creation team is not part of our development/QA team).
After the demo, the UAT team typically has two days to walk through the points and offer suggestions or changes. We consider these when deciding whether we delay the release or add tasks to the backlog.
2 Likes
I frequently demo automation tests or improvements to the platform that Iāve done. Usually I demo on the team level because we have dedicated time for this in sprint review. The tests and improvements I work on are directly relevant to the teamās projects though.
I enjoy demoing because otherwise the team/department wouldnāt have as much visibility of the good work I do. I donāt create fancy new features for the app, I write automation tests and keep everything ticking over nicely, itās a quieter role in that respect.
Demos help raise awareness of QA, and the progress of automation coverage. I think, to echo what others have said, if what youāre working on is relevant to the setting then demos are a positive thing!
2 Likes
For us it used to be a rotating system. Between Analyst, PO and Testers.
Now itās PO & Analysts because they are the most close to business and know what they want.
We demo what we made that sprint and if there were specific requests, weāll show those too
2 Likes
The Scrum Guide says this what the review is about.
Present what ever is need to stay with it. No matter who does it.
Beyond showing the product itself, this can include anything from test and development.
Sprint Review
The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.
During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.
The Sprint Review is the second to last event of the Sprint and is timeboxed to a maximum of four hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.
1 Like
probably should demo
1 Like
Donāt demo for the sake of it. Only do it if it has value to people. Ask yourself what the benefit will be.
2 Likes
comfort level be damned in my books - so the real problem is that we often see software as an opaque deliverable - and when we omit any kind of ceremony around that delivery, it becomes a lot like the kid who just chucks your newspaper over the front fence or just rams your nice printed copy of the Financial Times on itās lovely yellow paper through your letterbox. Some deliverables are impossible to demo, if so, ask yourself why itās impossible to demo.
You merely lengthen the SDLC cycle time, by not showing it off prior to dropping it.
2 Likes
I usually offer to demo, based on the fact that I know a lot about the product (from testing it) and can give a more holistic approach to giving information about it. Iām also a pretty good presenter.
But if other people want to do the demoing, then thatās pretty cool too. So long as the demo happens. Iāll usually be there and can add additional context or can talk about quality too, as needed.
4 Likes
In my team we all do it on a rotation for presenting the demo, what ever works for your team is the ābest practiceā.
That being said, in general presentation skills can be very beneficial for your career and doing a sprint demo presenatation might be a nice way to gently slide into this, by first presenting before people you know.
Great responses here, but comes down to simple criteria
- Who would benefit from a demo
- Aim of the demo
- Overall Goal
Whilst these sound the same - they are not.
Who : In previous roles, we have had QA demo to Business stakeholders, at my current role - we occasionally demo to the Product Owner if they do not have access to the environment to test. Other times, we have run a demo for Customers. The majority of the time, we get the DEvelopers to do a āhandover demoā to QA to show that they have met the base acceptance criteria!
Aim : Show features are as expected, or show what is possible (if you have an intuitive approach from developers).
Goal : For you to look good, or to evidence that the acceptance criteria/scope of the change has been met.
A lot of the time now - we have a UAT environment for the business - however, this can have its own issues where people are over critical and we have seen a lot of scope creep with things being requested that were not defined originally (But that is Agile I guess!)
Best advice - If it suits you and the team, do it. If not Donāt!
1 Like
Iāve worked in a mix of working practices including where Iāve been a permanent member of a team or joining just to test a chunk of work.
The majority of the time someone says āwe need to demoā and we all look away awkwardly. I donāt think Iāve been in an environment where demos would be exclusively one role. Usually it is a mix of:
- Who is best placed to demo - often the tester as they may have their setup still and have a wider view.
- Who most/least wants to demo.
- Who demo-ed last.
Our sprint reviews nowadays are almost like a news show:
āNow weāre going over to Rich to talk about this feature.ā
āThanks Sam. Hereās the feature that we completed. Now to Alex to share project progress news.ā
āCheers Rich. Hereās my bit, now over to Nicky who is on site in the lab.ā
I may have gotten sidetracked there. I think it ultimately depends on the point of the demo. Who should never matter. If you have something to contribute, then contribute. I would definitely advocate sharing internal wins like improvements to automation frameworks, test environment or similar.
I donāt quite follow this:
Regardless of structure, are teams demoing ācompleted workā that hasnāt been tested? If that is the case, IMO it isnāt completed and shouldnāt be demoed. Or are they demoing to you as the intended audience?
1 Like
Iām also going to again echo Richardās sentiment. The demo is a ceremony of not just closing or giving some work a stamp of approval. A demo is a interactive 2 way version of software delivery, some people donāt like closing the loop in person, thatās fine. You just need to ask yourself if itās healthy.
If thereās no ceremony even in some other form, then that circuit of your software development lifecycle is āopen-circuitā, and broken for efficient delivery of working software in the fuller definition of āworking softwareā. The ceremony might be that the department that wanted the feature gets it deployed via the IT software deployment platform, so every user gets the new functionality. This would apply for for example an API, which you cannot demo. but that mainly works because the exit criteria for an API are explicitly and implicitly captured with high accuracy, where-as exit criteria for how a GUI based feature is delivered is far more subjective and less about performance metrics than an API will be.
Iām probably being harsh with this take, butā¦ to me at least: The demo is a chance to share knowledge, skipping it implies that no knowledge needs sharing and that all knowledge has been captured in code instead.