By clicking the button “Selection confirmed” the selected images get a coloured green frame of 5px width, the current lightbox is emptied and all images are finally stored in the DAM.<\/li>\n<\/ul>\nThe acceptance criteria for our photographer’s user story could look something like this.
\nBased on these acceptance criteria, they can evaluate their proof of concept very well and ultimately decide whether the system is suitable for their purposes.<\/p>\n
Let’s briefly differentiate between the individual demo and the proof of concept:<\/h4>\n
With the individual demo, they also want to see that their user stories are implemented. The difference is that the proof of concept is a factual implementation of the stories on their potential system. Here, the complete functionality must be given, including hands-on experience by the stakeholders. An individual demo is more about getting an impression of how the user stories could be implemented with the system.
\nShould they now ask themselves: “And what happens next?”, “What about the integration?”.
\nThese questions are of course completely justified, but the integration of the system is not part of the selection process, but should be seen as an independent process. I will also address this topic at some point, including the correct testing according to ISTQB guidelines (ISTQB).
\nDo you have questions about the selection process, or about the structure of the proof of concept?<\/p>\n
Please contact me, I will be happy to help you:<\/p>\n
<\/p>\n
![\"Proof](\"https:\/\/i0.wp.com\/dam-evangelist.blog\/wp-content\/uploads\/2020\/09\/agile-software-auswahl-proof-of-concept.jpeg?resize=748%2C438&ssl=1\")
<\/p>\n![\"Agile](\"https:\/\/i0.wp.com\/dam-evangelist.blog\/wp-content\/uploads\/2020\/09\/agile-software-auswahl-akzeptanzkriterien.jpeg?w=400&ssl=1\")
<\/p>\n![\"\"](\"context.image.src\")
\n\t\t\t\t\t\t\t\t\t\t