![\"Lack](\"https:\/\/www.k-i-e.com\/wp-content\/uploads\/2020\/06\/295-en-01-Quality-of-the-Stories.jpg\")
The agile experts, who have all played an operational role in agile\nprojects, thus rated 91% of the stories from their respective practical\nexperience as not good enough. The experience from 10 years of Agile\nTransformation Coaching shows a similar picture: the quality of the stories\nabout different industries and diverse projects lies at a mere (5). This does\nnot mean that your industry or project are among them; it only means that if\nAgile Transformation was necessary, the quality was always an issue, which\nshowed considerable potential for improvement.<\/p>\n\n\n\n
The Quality Process delivers clarity<\/h2>\n\n\n\n
So, what can the team and the stakeholder do to ensure that stories are\ndescribed well enough for the next step in the process? The key is the Quality\nProcess. This is used and implemented in Agile Way of Working, especially in\nRefinement, as in all process transitions from the epic to stories. In classic\nprojects, space should be created to let the requirements mature in their\nquality.<\/p>\n\n\n\n
Story or request<\/h2>\n\n\n\n
On the requirements side, the product owner is the person responsible\nfor agile way of working; in traditional projects, the responsible person is\nultimately the project manager once the project order has been closed. The\nquality process focuses first on the person – the predecessor – who makes a\nrequirement and then on the follower as well as the agile implementation team. <\/p>\n\n\n\n
The product owner is responsible for the quality of the stories in the backlog, which represents the worklist. The quality reflects how mature the stories or requirements are before they become tasks in the sprint backlog. The required quality of the stories depends on many parameters, such as the maturity of the team and the maturity of the agile way of working. Typical of a quality story, however, are a priority, result type and scope, a short description, the goal being pursued, and the owner. Only when the stories are mature enough, in other words, when the agreed dimensions are described in the stories, does the product owner assign a quality index as a KiE number<\/a>. This is the assessment of how well the story is described from the point of view of the product owner. Good enough would mean an (8) on the KiE scale.<\/p>\n\n\n\n The agile team, in turn, provides feedback to the product owner via a\nKiE number, on the quality the story actually has for them and on their ability\nto implement the story well. If the number is between (8) and (10), the team expresses\ntheir appreciation for the Product Owner’s work. The agile values simply become\na fact of life, instead of being complained about. The agile team can work on\nthe story without further communication. <\/p>\n\n\n\n If the quality score is a (6) or (7), the agile team expresses that improvements are still necessary to do the job well. The agile team now has to inform the Product Owner via the resource question<\/a> of what is still needed to achieve a quality of (8) in the story. The slight increase in quality necessary is solved directly in the dialog with the Product Owner. The Product Owner can then give the agile team what they need to work well.<\/p>\n\n\n\n If the quality number is from (1) to (5), the story will be rejected\nbecause the quality is insufficient. In this case, the Product Owner has to\nconsult with the owner of the story again and deliver a higher quality. Here,\ntoo, the agile team is obliged to provide the resources so that the Product\nOwner can now do his job well. Through this process, everyone grows collectively\nand the agile way of working becomes more solid.<\/p>\n\n\n\n That sounds very simple and it is. At the same time, the Quality Process\nhas a great effect. Especially in projects that involve remote collaboration\nfrom different locations, people talk to each other with a clear orientation;\nalthough they usually find that only small details are missing, such oversights\noften lead to major escalations. Through the graded interaction, everyone\nexperiences that the resources needed to achieve a good result are in large\npart available. In fact, the integration of the quality and the DecisionMaking\nprocesses is a change that must be introduced, committed to, and made permanent. The integration of the\nquality metrics in collaboration tools like Jira or Trello requires only little\neffort. <\/p>\n\n\n\n When, after the Quality Process has been completed, so that the stories\nare clearly described and people understand each other better, the\nprerequisites are now in place for prioritizing and then determining in sprint\nplanning what will and will not be done. <\/p>\n\n\n\n After prioritization and sprint planning, the commitment process makes\nit easy to commit to the goal and to the associated stories for the sprint. <\/p>\n\n\n\n This creates all the conditions for a successful review, where\nstakeholders in turn can use the quality metric to appreciate the results\nachieved or send them into another loop for improvement. Thus, the loop from\nthe requirement through the epic, story and implemented result is closed. <\/p>\n\n\n\n All parties involved in the agile way of working now have the chance to\ndo the work well and the stakeholders to get what they need. The quality\nprocess is thus self-organizing and ensures a functioning cooperation and an\nappreciative approach. <\/p>\n\n\n\n People can achieve better mutual understanding, work more closely\ntogether and give each other a chance to do well.<\/p>\n\n\n\n Are you forced to work remotely or do you want to have everyone in the\nteam speak at the same time with automatic documentation? <\/p>\n\n\n\n Remote DecisionMaker can be used to map the quality process as well as the prioritization and commitment process. More mature agile teams implement the quality metrics in the backlog system and integrate the digitized DecisionMaker<\/a> in all agile ceremonies.<\/p>\n\n\n\n The poor quality of the stories, along with the lack of commitment and inappropriate\nprocess fidelity in agile methods, are among the dominant factors in the\nfailure of agile projects: “Research shows that 70% of complex,\nlarge-scale agile change programs do not reach their stated goals. (IBM 2013,\n2015, Forbes 2018, Standish Group 2019 with 84%). <\/p>\n\n\n\n A reference project was started with a classical project approach and\nwas about to fail with a subsequently measured velocity of 3 after 12 months.\nDecisionMaking and Scrum were introduced as remedial measures. Even though or\nperhaps due to the fact that the team was forced to remotely collaborate, the\nquality process took effect immediately after the introduction of agile way of\nworking.<\/p>\n\n\n\n The agile transformation took 3 months and after 6 sprints a stable\nvelocity was reached. The DevPos project was successfully completed after 16\nmonths. <\/p>\n\n\n\n Now take another step towards the agile way of working. Introduce the\nKiE Quality Process to your team and experience how the secure process\nincreases the quality of the stories and your chances of doing well.<\/p>\n\n\n\n You will develop a common understanding and grow together as a team\nacross disciplines. <\/p>\n\n\n\n We will gladly support you in this process.<\/p>\n\n\n\n The current crisis is forcing us all to work together digitally<\/a>. The shortcomings of making decisions together, which had already been apparent before the crisis, have intensified in digital cooperation. Companies now have to organize their work remotely and many people are trying to maintain their social contacts with it.<\/p>\n\n\n\n The freely accessible digitized KiE-DecisionMaker<\/a> solves these problems.<\/p>\n\n\n\n More articles about remote collaboration can be found after the sources below at tag \u201cArtificial Intelligence<\/a>\u201c.<\/p>\n\n\n\n _______________<\/p>\n\n\n\n June 2020 – Richard Graf, Elsa Graf<\/p>\n\n\n\n “Lack of quality is the top factor in all partially or completely failed projects.” Richard Graf<\/p>\n\n\n\n Graf, Richard: Die neue\nEntscheidungskultur: mit gemeinsam getragenen Entscheidungen zum Erfolg. Carl\nHanser Verlag GmbH Co KG, 2018<\/p>\n\n\n\n K. Beck et. al. (2001). Manifest f\u00fcr\nagile Softwareentwicklung. Abgerufen 02. Juni 2020, von https:\/\/agilemanifesto.org\/iso\/de\/manifesto.html<\/a> <\/p>\n\n\n\n Standish Group report 2019. Abgerufen\n02. Juni 2020. www.opendoorerp.com\/the-standish-group-report-83-9-of-it-projects-partially-or-completely-fail\/<\/a><\/p>\n\n\n\n![\"KiE:](\"https:\/\/www.k-i-e.com\/wp-content\/uploads\/2020\/06\/295-en-02-Quality-Process.jpg\")
This is how quality matures<\/h2>\n\n\n\n
Prioritization and commitments<\/h2>\n\n\n\n
Digitized services for the quality process<\/h2>\n\n\n\n
![\"KiE](\"https:\/\/www.k-i-e.com\/wp-content\/uploads\/2020\/06\/295-en-03-KiE-DecisionMaking-Processes.jpg\")
How to fail<\/h2>\n\n\n\n
Success Story – Velocity from 3 to 30<\/h2>\n\n\n\n
![\"KiE:](\"https:\/\/www.k-i-e.com\/wp-content\/uploads\/2020\/06\/295-en-04-Success-Story-remote-DecisionMaking.jpg\")
Now it is your turn<\/h2>\n\n\n\n
More about remote collaboration<\/h2>\n\n\n\n
Sources<\/h2>\n\n\n\n