Embedded Files
Fusion
A series of rapidly executing workshops to build the project vision and consensus amongst the internal and external stakeholders. With a common understanding of project goals established, client and Knoldus teams can then define and prioritize requirements, success factors, and create a roadmap based on key business and technical considerations. It drives clarity, accelerates delivery, and helps achieves business goals.
The project tooling is also set up during this phase. This includes
Project Management Software -
Source Code Repository -
Wiki -
Asynchronous Team Communication -
Synchronous Team Communication -
Decide on integrated standup time
Duration - 1 Sprint
FUSION STEPS
I. Research and Requirement
SAMPLE OF ARCHITECTURE EVALUATION AND DETAILING
HOW FUSION PHASE WORKS
KEY CONTRIBUTORS OF FUSION EXCERCISE
Business Leader
Product Manager
Architect (DevOps, Data, Infra, Application)
Architecturally Significant Use Cases
Architecturally significant use cases have an impact on many aspects of your design. These use cases are especially important in shaping the success of your application. They are important for the acceptance of the deployed application, and they must exercise enough of the design to be useful in evaluating the architecture. Architecturally significant use cases are:
Business Critical. The use case has a high usage level or is particularly important to users or other stakeholders when compared to other features, or it implies high risk.
High Impact. The use case intersects with both functionality and quality attributes or represents a crosscutting concern that has an end-to-end impact across the layer and tiers of your application. An example might be a Create, Read, Update, Delete (CRUD) operation that is security-sensitive.
After you have determined the architecturally significant use cases for your application, you can use them as a way to evaluate the success or failure of candidate architectures. If the candidate architecture addresses more use cases, or addresses existing use cases more effectively, it will help usually indicate that this candidate architecture is an improvement over the baseline architecture.
Expected Output
Tooling to be used on the product is decided. Preference is given to the Knolway toolset
The common understanding of project goals and roadmap formed and documented on the wiki
Initial Product Backlog prepared with the Stakeholders
Architecturally significant stories identified
High-level story estimation is done using the Planning Poker method for items in the product backlog
Below is an example to categorize features to be developed and the relevant stories.
BENEFITS OF FUSION EXCERCISE
Checklist for executing Fusion exercise is completed
The team should be looped-in on the next objectives/roadmap
This happens during the monthly kickoffs
PM, BA discussion
o Review Business Case and prioritization / current targeted delivery date
o Verify business requirements
o Consider any privacy concerns
o Consider any legal concerns
o List out any known out of scope items
o Document use cases, including successful flow (“happy path”) and alternative paths.
o Document and link external team dependencies in Confluence or Wiki.
o Create feature / epic in JIRA
Include Security review form (high, medium, low risk)
PM, BA, Architect, Tech Lead discussion
o Discuss business requirements & use cases
o High-level feature
o Discuss dependencies
o Discuss if any Service Level Objective metrics are impacted
o Do we need to include integration or validations for the developed services.
Architect, Tech Lead to provide architectural designs, documentation, technical dependencies on external teams (cloud engine, app owners, Database
o In some cases, a Dev could provide these artifacts.
o High-level estimates and story breakdowns.
If UX or User Research is needed
o Kickoff discussions with UX, Team for UX designs or research studies needed for the feature.
o UX creates mock-ups or defines goals with Product for the user research studies.
o UX conducts studies.
o Review study results.
o UX tweaks mock as-needed.
Feature kickoff discussions with the whole team (or as needed) to discuss epic feature, vision, scope. Team decides:
o If feature breakdown is needed.
o If technical research is needed.
o If technical discussions are needed
o Discuss high-level dependencies
o Discuss high-level estimates and estimated timelines to complete feature
o Discuss QA strategies
o Finalize technical strategy with Team
o If business objectives or use cases should be further defined
o Identify SMEs from other teams
The team breaks down stories (dev and QA added as optional), which can include:
o Development stories
Front-end stories
Back-end stories , e.g. Command service, Query service, new endpoints
o Pipeline stories for dev, staging, prod, sales
o Testing stories
o Documentation story
Page updated
Report abuse