These types of tickets come in phases where many of the branches can work in partnership moving the designed application forward with some autonomy.

These tickets are iterative and often are labeled the “Sprint 0” depending on the ask from the product owner and how developed the concept is before the team receives the project this will be iterative. Often this should be a set of meetings and reviews between the UX Team and Technical Architect and Front-End Senior Lead with responses sent back to the UX team and ultimately the Product Owner. Depending on how “Lean” you want to run the project this can be as lean as a rough sketch where the particulars are hashed out in the project to full-blown comps with requirement notes being captured in the Parent “Epic” Ticket. Initial talks of analytics should be talked about prompt the BL to reach out to the analytics team to establish this branch of the requirements.

When the receiving team is comfortable with the clarity of the intended product this phase will break down the ask into dispersible tickets. Depending on the skill and resources these tickets can be sized appropriately for the team. Basic Application Construction can start on day one considering the scaffolding is fundamental to any other work.

Independent work is brought together in this phase. It is common that co-working and JAD sessions occur in these tickets as team members bring together the individual efforts. There is no clean break of this phase to previous depending on the delivery it is common that a feature might go through all phases and be QA’d before other features are even started.

Design Phase is the most prone to change. This phase should be mostly completed before the rest of the tasks should start. There is always reason, technical or just iterating over an experience that can cause changes to the design but if the team has a good idea of what is being built and rework will be reduced. The tenants of AGILE does allow for iteration so it is inevitable that rework or alteration will happen. Documenting for the team should migrate to comments on design documents because living design documents are costly and in the end are a non-production artifact. It is very important that the Technology Team (DEV & UI Lead) break down the steps and familiarize themselves with the nuances of the features to intelligently question the design and highlight possible issues before alterations become more impactful to the timelines. QA at this point can even scaffold out User Tests on features during this step.

Team review of the UX design of Project X. Highlight and Flag and Feasibility Changes and Iterate over them with the UX team. Team will submit a scaffolding of tickets to produce the Application. Details should include Data needs, Implementation Specifics, Analytics definitions, and Front-End Breakdown.

These steps are mostly dependent on the previous and could be collapsed to a single ticket but the ambiguity of the Data API it is best to keep these tickets into separate tickets to utilize a wider base of resources.

API & Data Structures to support the application outline the data handshake and return results for App Build Team & UI Team.

A user may only visit the URL if the user is logged in. The page will do all needed steps to redirect the user through log in in needed and redirect the user back to the page after success. Define URL & create the hosting page in Sitecore.

A user should be able to visit a URL and have an application on that page respond to the visitor with the information it has available to it. Create the shell of the application and establish needed hooks to the data the application will know. This information is defined by the project but in the most basic definitions the application will know about the User, and possibly the URL and any query structures.

When the user visits the application, and it is loaded the application will initiate and collect information through API calls to store any data that is needed to display information and formulate any actions needed for the user defined by the project.

Components should follow the single tenant that they are only responsible for data passed to them and emitting their context. This separates concerns when the Application takes most of the features and components can stay agnostic.

When creating components all new components will be created with the library’s project folder. If the team finds value for a specific component that is generic enough to be reusable across many applications, the component can be promoted to a common library folder. Be aware that common components require a greater level of flexibility and scope to make them bullet proof for generic consumption.

Component tickets should encompass basic mutations that are needed for that component. Basic examples or mutations are Size, Location or Inclusion, Props (Data they will display), Validations, States, Etc. This should result in a Code Review and a Demo with UX Team and Product Owner. To reduce meeting overload, they can be grouped with other tickets or be deferred to the Feature Refinement Ticket

The user should be able to see the data they need to see and interact with data as defined by the requirements this is known as feature. In many cases features can be scaffolded with their data and methods without the need of utilizing components. Operations of an application like looping, reductions, additions, removals, data hooks and server responses can be all worked out without the use of components.

User should be able to do X Feature.

For Example, “scaffold delete this line item from the list.” This will produce a data storage, list and methods and listeners that can be used to remove data from the list. This would also include any database API and deal with the response return updating the stored data of the list.

Inclusion of components and refinement of the frontend features. These phases will “wire” data and properties to components into the application. Depending on the size of the application these can be broken down into Features, or Pages, or States. This is the moment where components are due from the front-end teams. The deployment of components can be more staggered if the team is more comfortable with constant deployments. The benefits of this would be a lister would be available much earlier in the development process but may need to be updated or rewired if changes to validation or data needs alter in the refinement process.

User should be able to do X Feature in the App

For Example, “A user by clicking on the delete button on a list item should delete it from the list.” Render a data list with the delete button. On the click add a listener to the application that will trigger the delete feature that has been scaffolded. QA this feature. Demo this Feature with UX Team and Product Owner.