This “puzzle” approach leads to some or all of the following problems: Who wants to build business operations and software like that? Yes, you can put the picture together from the pieces but the whole idea of a puzzle is that it is meant to be difficult and take you a long time. When user stories are plucked out of conversations with users about complex business operations instead of being derived from models of those operations, you can be left with a jigsaw puzzle instead of a picture of those operations. User stories do not exist in isolation from one another. Yes, I know Agile is meant to allow you to quickly iterate and enhance but that is too often used as an excuse not to do any analysis or planning. My experience is that when the user story is the only technique available to POs and BAs, avoidable misunderstandings always come to light during playbacks, testing and even in production. In some cases, the POs received no training at all prior to taking up their role and had no Agile Coach to guide them. I have been on a few projects now where the Product Owners were new to the concept of user stories. This blog post is in the context of complex business operations. However, I have never worked on a project where the processes were not complex and I have found that it is the process models themselves that tell you what your candidate user stories are (although not all of them will come from process models). If the team were building a process to allow employees to claim back business expenses, I would not spend a lot of time modelling the process because the process itself is unlikely to be complex. Most Product Owners I have met do not have a method for identifying candidate user stories or deriving acceptance criteria for those stories.ĬAVEAT: I believe you should only model to the level of detail needed, regardless of what type of model you are using.
0 kommentar(er)
