<Architect for Developers>
A product known as the ScopeMaster® belongs to the emerging resources that can significantly improve the work of Agile Teams such as Scrum Teams and DevOps Teams. This product automatically analyses articulated business tasks, requirements or User Stories against the integrity, complexity, consistency, clearance, and can perform other tasks like supporting GDPR and estimating programme/project complexity on the basis of functional points.
The power of this tool is in overall, end-to-end revision and analysis of the requirements /User-Stories. The more information is available before coding starts, the more accurate the analysis results can be achieved. There may be several different algorithms for applying the ScopeMaster® with related efficiency and effectiveness, but the trickiest of them is when the expected or new User Stories come at the pace of consecutive Sprints. The Team does not know what the next requirement for the ongoing solution work might come.
In other words, at the time of the Sprint 1, the Product Owner and the Team might not know how the results of this Sprint will impact the Sprint 4 and vice versa. The ScopeMaster® may be applied to each individual Sprint and help to clarify a particular set of User Stories. However, the more Sprints in the implementation process, the more uncertainty of cross-impact and inter-dependencies between the Sprints the Team has and the less reliable outcomes of the ScopeMaster®.
Such kind of problems (impact of the edge conditions) is well known in mathematics. I’ve got a solution for one of those problems that I applied for AI/Pattern Recognition and, later on, described for Project Management. In this article, I describe the special algorithm (a sequence of rules) that we recommend for maximum effectiveness of using the ScopeMaster® during development process across multiple Agile Sprints in the Team.
Assume that the Product Owner or Project Manager, or Business Analyst has collected business functional requirements (you can find a review of the ScopeMaster® with current pros and cons here). The different methods of how to perform this work are out of the scope of this article. For the Sprint 1, we can have a text file or another structured source of User Story text (of requirement statements) and specify it for the ScopeMaster®. The latter reads the text and performs the analysis according to its configuration set earlier. The analysis outcomes are documented for future references.
In the Sprint 2, we can clone the operations with the ScopeMaster® from the Sprint 1. However, the context of the Sprint 2 has changed already – there was the Sprint 1 with its results and consequences. If we ignore them, our analysis and, therefore, implementation has a high risk of being incorrect because nobody has taken a duty to split Sprints absolutely clear with no interdependencies. In order to consider this changed context and potential internal links between the Sprint 2 and Sprint 1, we join the requirements/User-Stories of both Sprints and submit them into the ScopeMaster®.
Going forward with more Springs, we will do the same – we will enlarge our set of requirements/User-Stories with each new Sprint up to the last one and re-apply the ScopeMaster® again and again. Well, it is not that simple as you might think at the first moment. The matter of fact is that when you re-run the ScopeMaster® for an enlarged set of requirements, the outcome can point to the problems in the requirement for the previous, already implemented, Sprints. This is natural and logical – the fewer requirements you have for analysis, the less internal links they have. If you would way all User-Stories altogether by the Sprint 1, your analysis can be run just once and found all critical and tests for the whole development process. Agile development does not have this luxury and has to minimise the risks of missing important links by performing more work.
Thus, when we have only Spring 1 and 2, and after we have run the ScopeMaster® for both sets of User-Cases and found a requirement gap for the Sprint 1, we have no other choice than return back and refine the implementation of the Sprint 1. In other words, with each next Sprint, we challenge our understanding of previous Sprints and re-balance/refine the implementation with new knowledge. The entire algorithm is illustrated in Figure below.
As a side-effect of this process, it is highly recommended to reduce complexity and number of implementation tasks for earlier Sprints in comparison to the later ones to reserve resources for the backward refining. If requirements/User-Stories are collected along the Sprint schedule, it is possible that some inter-dependencies between Sprint-by-Sprint implementation are considered in the requirements. The power of the ScopeMaster® is in that it can uncover more and more unnoticed dependencies the amount of requirements/User-Stories for the analysis becomes closer to the full amount.
The first result of this uncover is a need in the possible backward refinement of implementation performed in the previous Sprints. The second result may be applicable to such Agile Development model where each Sprint is supposed to deliver an immediately deployable functionality considered as a minimum viable product. Particularly, hidden interdependencies between implementations of Sprints challenge the sustainability and accuracy of the definition of minimum viable product for consumers. If the discrepancies are found for the requirements/User-Stories for already released elements of the product, this can cause business risks for the company because the consumers should be informed about issues in these sold elements. These may be reputational, compliance, financial or security risks, for example. Such risks may be partially mitigated by additional up-front analysis of requirements and artificial delays of the product element deliveries when the ScopeMaster® outcomes show minimal backward impact of new Sprints. This is a specific decision for each case in each company.
Another consequence of uncertainty caused by agile requirement gathering is the to-be anti-Lean manner of Sprint implementation. It does not make much sense to polish each Sprint (remove all “waste” considered today) in anticipation of refinement tomorrow. Again, we mean not new requirements sent toward the development team, but the discrepancies uncovered by the ScopeMaster® analysis for the next Sprint. In general, Agile development strongly contrasts the manufacturing development style where everything is known and specifies up-front. That is, in Agile implementation, we do not know what is the “waste” until we finish the implementation of the entire business task.
At the end, we have to outline that re-run of the ScopeMaster® several time during the project is not complex or timer consuming task. An analysis of 100000 requirements/User-Stories takes just a few minutes. The laborious part is re-factoring (if it is permitted). So, we can recommend to use such style of implementation that permits maximum flexibility in spite of it might need to perform a bit more work than the User-Stories explicitly ask for.
HOW to ARCHITECT for DEVELOPERS 