Date

Time	Item	Who	Description	Goals/Info/notes
5min	Administrivia	Cornelia Awenius		Note Taker: lisa perchermeier meeting_saved_closed_caption.txt
45 min	PO perspective: life cycle of a feature	julie.bickle	1] Define the need in as much detail as possible: Organise talks; elicit feedback. _“What is the problem? What are we trying to solve? What does the user need? What are the most common use cases? What are edge cases that should be accounted for” _ Then translate into FOLIO! 2] PO writes the stories based on the SIG input. 3] Back and forth discussion with the devs to write finalise the stories. 4] Devs develop; PO is available for questions and needs to validate (business) functionality in Snapshot, then Flower. 5] User Acceptance Tests – try out your own workflows 6] Communication and documentation 7] Take on Bugfest tests! Please….. 8] Bug alert! What to do: _ Narrow down the circumstances as much as possible; which options; intermittent = (exploratory) task, not a bug. _ Replicate in Snapshot, current release and previous release (i.e. regression?)

Meeting Notes

At Wolfcon there was a session about the recruiting of POs and in the last RA SiG meeting the question how to move things forward was discussed. There´s an idea to have assistant POs or to form a subgroup to assist the PO.

Julie: If SIG helps, there is no guarantee that development moves on faster but maybe it can help to save time the PO can use to move things on.

Presentation:

Julie presents the life circle of features (please see steps 1-5 above, the bold ones are those Julie can imagine the SIG may be able to help with) – below some additional information for each step.

1) Gather as much information about the new feature as possible, check which effects it might or should have on other processes. Make sure no cross actions are triggered by the new feature that might not be desired (repercussions). Try to figure out the whole network of what can happen through this new feature. What should happen when and in which order?

It would be helpful if the SIG or a subgroup jumps in.

2) Stays with PO – an official PO should own the Jiras to reduce contact persons

3)Iterative process – PO handles discussion and comes back to SIG in case of open questions

4) -

5) The PO does more of a business acceptance test and checks if requirements are met.

Additionally it would be very valuable if the SIG members could organize user acceptance tests that may include

User tests in real life workflows
Check if scenarios might have been forgotten

These may not be easy to carry out, a lot of preparations may be necessary
Steph Buck did this for TLR. Julie will ask her how she did it.

6) Presenting a feature to the SIG when it is there and documentation (help Erin, update Wiki)

7) Please take on Bugfest tests or recruit people to take part. There will be more time for PO for other things

8) Helping in case of bug alert for example on slack. Try to find out what the problem is exactly, replications of steps, test against different versions. That will leave PO more time to do other things

Discussion how to move on:

Assistant PO work / subgroup for assist the PO

Julie: The idea of an assistant PO would be to act as an owner or champion for a special feature and be part of getting it ready for development.
Andrea: Willing to commit but it is not clear yet what exactly has to be done, where to start and how much time has to be contributed
David: Does the SIG have the background to decide between different options
Julie: It would be about exploring the different options, ask questions in the sense of an iterative process, to find and ask people who can help on the way
Andrea: A walk through with a specific example UXprod would be helpful

To be scheduled when Jana is back.

Bugfest:

David: Problem with Bugfest testing is that the testers have to be trained.
Cheryl: For colleagues who already work with productive system it is difficult to switch to a system with unfamiliar settings.

There are plans to rework the data and base configuration used for Bugfest.

Cornelia: The test stories should be written with more context, otherwise bugs might not be detected.
Julie: Vega and Epam teams have a Q&A person who writes the tests. The better the stories are written the better they can be used as test stories. Difficult to address – maybe to be discussed. in a separate SIG meeting.

Browser not supported