Abstract

Popular methodologies tend to revolve around larger objects like Stories or Epics, while development teams tend to prefer breaking those large objects down into smaller, and more technical, work tickets. This is often done through research, software design, architectural, or any breakdown processes where the team figures out the best way to implement the overall request. When this happens, unique problems arise with modern methodologies. The Feature Focused methodology was created to handle these problems for teams where other methodologies do not fit.

Concerns with Software Design in Modern Frameworks

Methodologies, or “Frameworks”, such as Scrum and Kanban seem to prefer entire stories or features to remain as a single ticket throughout the process. The idea is that the feature should naturally be small enough to complete in one sprint (for Scrum) or in the targeted throughput (for Kanban). Many features require some form of software design (sometimes known as architecting) to take place. It is this process that can often break the implementation of said frameworks. In an attempt to fit this research and analysis work into the team’s current process, the team may try to estimate it like other work, pause the sprint cadence while the architecting is done, or move the architecting to a specialized group and out of the team’s control. Other issues arise when that software design creates implementation tickets to facilitate building the feature in smaller chunks. If this creation of new tickets occurs during a sprint, or past Kanban’s ‘Line of Commitment,’ where do the implementation tickets go and how does the team ensure all of those new tickets gets completed and tested together?

Secondary to the problems with architecture are the personnel concerns with modern methodologies desiring a team of ‘Generalized Specialists.’ These are software developers who have specialized knowledge in specific skills but basic knowledge of the business domain and software development in general. In some fields it is almost impossible to achieve this, or an expert may be loaned to the team to implement a feature that requires their doctorate level knowledge. Take for example the field of aerospace engineering where you have individuals with deep knowledge in a particular focus that you cannot expect a general software engineer to have or be able to obtain. This often causes subject matter experts to become a bottleneck in your processes. Feature Focused attempts to resolve all of these concerns by building a workflow around them and focusing on the feature as the core unit.

Feature Focused Methodology Introduction

To solve the problems of software designing and breaking down stories into usable work tickets, Feature Focused incorporates the architecture process as the key, and often most time consuming, part of the feature workflow. The creation of work tickets is highlighted, and all tickets remain attached to their parent feature, the group of tickets then moves through the process together, and finally everything is tested against the architected design before being approved for release.

This is accomplished by having the standard backlog grooming to prioritize the features, architecting to pull out appropriate technical tickets, working through those technical tickets, merging them all together for feature and integration testing, before sending the feature for a release.

The Feature Focused philosophy tries to front-load the work into the architecting phase and render all other work into a standardized and almost trivial effort. If more time is spent making sure all the information about the feature is well understood, the needed documentation for the feature is properly created, and the technical tickets can be followed by any developer, the less time will be spent implementing the feature. Blockers, extra research, trying to understand old code, or other events that often reduce the efficiency of the team are eliminated before coding is started.

Feature Focused Workflow

The Feature Focused workflow can be seen as phases each feature passes through until completion. These phases are known as: Prioritize, Commit, Architect, Work, Test, Release. This workflow happens for both features and defects (bugs) with minor adjustments between the two.

Prioritize

For the PRIORITIZE phase, the product owner (and/or representation from the development team) performs backlog grooming to assess which features and defects are approved for work, as well as establishing or adjusting their priorities. This should include both the customer’s and development’s requested features to better understand the needs of both and is often useful in a grooming meeting with representatives of both sides to effectively state their desire for their features. Ideally only features that have been given a full product design are prioritized, but that is checked in the next phase of the workflow.

Commit

The Feature Focused workflow adheres to Lean philosophy, similar to Kanban, in terms of creating a flow, establishing pull (not push) of items through the system, and deferring commitment with the Line of Commitment. This adherence creates the COMMIT phase in the Feature Focused workflow and involves pulling features to begin architecture. It is the development team’s responsibility to only pulling in features deemed ready to be architected.

If the team does not select the features in the product owner’s chosen priority, the rational must be documented and attempt to resolve the concerns should be made. Examples reasons the development team may not approve of a high priority feature include:

• Lack of information – The development team felt they could not successfully complete the work based on the current information provided in the feature or defect ticket. This includes having all product design finished, requirements or user stories fleshed out, appropriate wireframes or UI concept images created, listed steps to reproduce the defect, etc.
• External dependency blocks the work – There is a known external dependency (i.e. blocker) that the team feels will prevent the work from successful completion in an appropriate timeline. The dependency should get reviewed, documented, and the most appropriate group (being the team, product owner, or the customer) should attempt resolve the dependency; allowing the feature may be re-prioritized.

Once the team pulls a feature across the Line of Commitment, only a rare or exceptional event can force that feature to be withdrawn; standard priority changes do not merit such a change. This concept is needed to ensure the investment of time given to architecting is not wasted.

Architect

After committing to a feature, the ARCHITECT phase starts to fully understand the feature from a technical aspect. This phase begins with the assignment of the architect. The architect is the person responsible for the feature and shepherds it through the rest of the workflow. This includes performing the architecture work, coordinating with any outside assistance (such as the test team), resolving any problems the development team encounters during the work phase, providing status of the feature to the product owner, supervising testing, and generally assisting anything needed to make sure the feature is completed successfully.

It is the use of the architect that solves the ‘generalized specialist’ problem. By having the subject matter expert be the architect, they can solve any formulas or create any specialized designs before creating technical tickets used to implement those designs. Then, as the architect, the expert supervises others implementing the designs as needed.

Feature Focused architecture follows a series of stages to produce everything needed for the success of the feature. This involves reviewing and confirming the product design, researching the existing code, identifying a technical solution (including any new technologies that need to be introduced), breaking down the work into smaller, coordinated, technical tickets, documenting the feature, and creating the testing for the new feature.

1. Review & formally document all requirements – Requirements may come in as user stories or otherwise nebulous in nature. Derived requirements will need to be created, and all requirements will need to be understood and validated with the feature's point of contact (PoC). This stage my reveal changes or updates to the requirements that will need to be documented.
2. Identify components to update – Both as a first pass and later as a refinement, identify and review what areas of the system are likely to be affected.
3. Research current code related to the feature – Take a more in-depth look at the areas identified that will need to be changed to understand and possibly document how the affected components currently function.
4. Design the UI & potential edge cases with the PoC – An iterative stage where the architect works with the customer PoC to ensure any UI directions follows what the customer wants, and potential edge cases or error handling aligns with the requirements, UI, and scope. An example of this would be the architect identifying every potential error message that may be displayed and working with the PoC on what each error message should say to the user.
5. Design the technical solution – The namesake of this process is to architect how the feature will be implemented into the current code base. If everything above has been done well, the architect has a clear understanding of what needs to be done and how it fits into the code.
6. Ensure the technical solution matches the requested scope – The solution the team will implement should match the scope of the feature. Anything less or more can cause future defects, so the architect should double check they have solved for the request and nothing more.
7. Create technical tickets – Often the bulk of the architect work, the technical tickets are created and ensured they contain all required information to be executed successfully.
8. Review test cases required – An overview of what testing is needed for the feature should cover both the new work as well as any areas that may be affected by it. The peripheral areas are important to capture to reduce potential unintended consequences. These tests cases should be written or updated, and then reviewed with the feature's PoC to ensure the scope of the work is appropriately covered.
9. Perform a tech review – Finally, with everything in place, the feature and technical tickets should be peer reviewed by the development team to make sure nothing was forgotten, the team has a chance to ask questions, the team can learn about the feature’s design, and that all outstanding concerns have been answered.

Once complete, the architect has generated technical knowledge about the feature, the solution of how it will be implemented, and technical tickets to execute the solution. The technical tickets are then given the entire team to begin work. Note, due to any previous feature still being in the work phase of the workflow, work on the technical tickets may not begin immediately.

Work

In the WORK phase, the development team picks up technical tickets and implements the required updates or produces new code. This phase includes the production of code, build scripts, unit testing, or even automated tests; whatever is necessary for the product to include this feature. This phase is often the focus Kanban and Scrum as it is considered producing value for the product. While that value creation does happen in this phase, Feature Focused reduces the scope to pure generation product. In other words, it is the goal of Feature Focused to remove all ‘guesswork,’ ‘figuring out,’ or problem solving from this phase and give the developers the well-written direction they need to enact the design flawlessly.

This does not mean that the architect needs to write the tickets so detailed that the developers have the exact code to drop in. We must trust the generalist developers to use their skills and knowledge perform their work, so technical tickets should be simplistic enough to avoid the need for the developer to design connections, interactions, or data flow, but not so simplistic that the architect is writing all of the code while architecting.

The work phase ends when all technical tickets have undergone peer/code review, and the entire feature is ready for functional and integration testing.

Test

The TEST phase ensures everything is appropriately tested and vetted. It is the architect’s duty to supervise the testing of their feature, whether that be monitoring and approving the testing done by a test team, or by facilitating the testing initiative within the development team.

The testing of technical tickets should be reported to the architect during the peer/code review process during the work phase. Feature testing, known as integration or factory acceptance testing is done by the architect, the test team, and/or someone designated by the architect. If the architect performs the tests, then a third party should review the results and/or monitor the testing.

After all testing is done the architect makes a final review of the code to merge it into the main code branch. They then review and update the feature documentation for any changes that had not been captured, update the release documentation, and ensure all feature artifacts (such as test results) and properly stored. The feature is the ready for release.

Release

Once a feature is complete it can be released by itself or placed in a release package where any number of features queue for release. The decision on when to release is the purview of the product owner who should have a full understanding of which features are ready and how the release would impact users. It is their discretion if a release waits until the next feature is complete, to release on a monthly cadence, or however decide when timing is right. No matter how a release is decided the feature is done, and the team may pull in the next feature.

Defects

By their nature a defect is a non-conformity in the system; an error in the software design or implementation of the design that needs to be corrected. Defects goes through the same workflow phases as features, with the exception that a defect should not need architecting. If the defect is a problem in the original architecture, then the designs and documentations of that original feature should be updated.

If the original error in the design is so egregious that it warrants a redesign the defect should be promoted to a new feature to follow the feature workflow.

Feature Focused Ticket Types

As mentioned in previous sections there are three (3) types of tickets: Feature, Technical, and Defect.

Feature Tickets

A feature encapsulates a distinct element of functionality. In software this functionality generally has UI, back-end, and maybe database parts. It is often large enough to warrant multiple tickets for implementation and distinct enough to fully test. Features may contain multiple requirements, user stories, technical artifacts (e.g. mock-ups and data flow diagrams), estimates, customer priority, and other information deemed important for the entire breath of the work. This should all be in, attached to, or otherwise included with the feature ticket. Basic information includes (but not limited to):

• The feature's customer Point of Contact (PoC) – Who is the source providing information about the feature? That person should be available and capable of answering any questions about the feature's end-result and have the authority to make design decisions about the feature.
• User Stories – What is the expected results (sometimes known as the "Happy Path") of the feature? What scenarios are there of a user's work with the completed feature?
• Requirements – These are the user stories broken out into distinct requirements. Requirements may be explicitly stated (such as "All password fields must be obfuscated") or implicitly inferred from other requirements or user stories (such as the requirement "users enter the site with their unique username and password" leads to the requirement of user accounts).
• A limited & defined scope – The work should be finite and encapsulated into a singular feature that is itself indivisible into smaller features (the distinct element of functionality. For example, if creating a login webpage, the scope may be limited the UI, username and password, and the login process. It should not include account creation, updating one’s password, or additional items that could be their own features.
• Declared deliverables – Along with the scope, the deliverable should also be clearly defined so the team knows when to stop. As with the example above, the deliverable for a login webpage should not include anything for those extra features or subsequent work.
• Defined UI – With or without mock-ups, the feature PoC should have details on how any required UI should look and behave. Depending on the team, this may be as broad as a general idea of the UI or as narrow as pixel perfect screen mock-ups with complete diagrams detailing what every button does in every scenario.
• Known nuances or pitfalls – Anything the feature's customer PoC is aware of that the team should avoid or be careful with while working on the feature needs to be included with the feature. This may include sensitive data handling, likely errors in input data, future feature designs, or technology limitations.

Feature tickets group the technical tickets, have their status updated as they move through the Feature Focused workflow.

Technical Tickets

Tickets produced by the breaking down and architecting of a feature are known as technical tickets. The development team then works on technical tickets to enact the feature. Technical tickets get reviewed (either through a code review or document review) before being merged into their main feature branch. This type of ticket can be anything from updating documentation, to writing code, to DevOps work; anything the team must do to implement the feature into the greater system should be laid out in technical tickets. Technical tickets should be ordered/ranked within the feature to ensure work appropriately flows without major blockages or interruptions.

Each technical ticket should contain everything it needs to be successfully understood and fulfilled by the team member that picks it up. The size of a technical ticket should be complete enough to be tested on its own (either with unit tests and/or functional tests) but small enough that an individual team member can successfully accomplish the work in a reasonable amount of time. Technical tickets can build upon each other by properly linking and highlighting prerequisite work. For example, a single ticket that requires the UI, REST endpoints, server, and database updates is likely too large. Instead, each of those areas are better as individual tickets that properly rely on the lower layers to be built first.

Defect Tickets

Bugs found during testing, and non-conformance found after a feature’s released, receive Defect tickets. Defects found during the testing of a feature are included in the feature’s work and should be complete prior to release. Non-conformance issues are defects found in acceptance testing, in the live environments, or generally after a feature has been merged into the main source code. These non-conformance defects are prioritizing alongside of features and receive integration testing before being merged into the source code.

Board

The Feature Focused board is split into multiple columns (or swimlanes if using a virtual board, see below). Each column is either a single feature with a header containing feature information or a group column containing loose defect tickets. The group columns are either Approved Defects (defect tickets that have been approved to work on), Critical Defects (defect tickets with a critical timeline), or Backlog which holds both feature and defect tickets not yet ready to be worked on. The feature columns can move around the board while the group columns are set at specific places.

Within the feature columns there is the header and a prioritized list of technical tickets. The feature header contains information for the tracking of the entire feature. This includes feature title, ticket/feature number, and due date (or date based on estimated time). Each technical ticket and defect ticket shows (at minimum) its title, ticket number, status, assignee, and (is active) flag; an active flag signifies that the ticket is having problems that the team should actively be attempting to fix. Technical tickets within features remain no matter what their status is (to retain visibility), while tickets in the group columns disappear off the board once they are in a resolved state (being “cleared off the board”).

Example Board

The board attempts to display the more important work to the left of the less important work. While this flow is backwards from most styles, most languages read from left to right, so this assists the development team in finding the most important items to work on first. The left-most column is the Critical Defects group column. This column should remain empty unless there is a critical defect that stops all other work.

After the Critical Defect column are the In-Progress Features section for the team to actively work on. Depending on the size of the team, this can be from two (2) to four (4) features. Similar to Kanban’s Work-in-progress (WIP) limits, the team should restrict the number of features allowed to better promote completing the current features. This means that the number of team members acting as architects is also limited by the column number.

Next to the In-Progress features is the Approved Defects group column. This column contains defects the team has been approved to work on if no other feature work is available. No more than five (5) to eight (8) defect tickets should be in this column at any given time and the backlog of defects helps determine if a new feature is put in progress or if the team spends extra time clearing out the Approved Defects column.

After the Approved Defects column is the “Line of Commitment”. Anything to the left of this line are features and fixes the development team has explicitly promised to finish in a timely manner and cannot abandoned.

To the right of the Line of Commitment column are two (2) to five (5) Prioritized Features columns that contain features already prioritized and are ready to be architected next. Finally, the right most column is the Backlog group containing everything else that has any priority.

Using Virtual Boards

Virtual boards such as Jira may facilitate rotating the columns into swimlanes. This would create the swimlanes of Critical Defects, Features in Progress, Approved Defects, Planned Features, and Backlog. The use of components, fix version, or other tags are needed to place the features into the correct swimlane.

The added benefit to this style is that the columns then show the technical ticket progress with Planned, In Progress, Blocked, In Testing, Done, or whichever technical ticket statues are preferred. Features (or Epics) are then transitioned along the columns with its status changed by the architect.

Critical Defects

Defects that are critical in nature, work that must be done immediately due to some emergency event, move to the Critical Defects column. At which time all other work should cease, and the team’s sole focus should be resolving the critical defect immediately. Note that features never belong in the critical defect column as a ‘critical feature’ is just the top priority feature which may receive a release as soon as it is complete and allowing features to be considered ‘critical’ only encourages ignoring safeguards and testing.

Documentation

Beyond the standard code comments, ticketing system, and meeting minutes, Feature Focused encourages maintaining a list of supporting documents to assist the workflow and releases.

• Release Feature List – The master list of features that have been completed since the last release (can be organized per release). When the customer/Sponsor approves of a new release, this list becomes the basis for release notes.
• Feature Documentation – Each feature should receive architectural documentation. This may be as simple as updating a user guide or existing documents to include the new functionality, or as complex as creating an entire package of graphics, diagrams, write-ups, mock-ups, and artifacts.
• Testing Results – As each feature and defect has integration testing performed on it, the testing results should be captured for posterity and release review.
• Monthly Metrics, Improvements, Lessons Learned – While the main metrics for any Lean project are working product and throughput of features, team metrics are maintained for self-awareness and improvements.

Roles

Feature Focus reduces roles into several main categories:

• Development Team – Referred to as "the team", these are the people performing the work and includes the developers/engineers, direct functional manager, project manager embedded with the developers, architects, and the testing engineers. Within the Feature Focus methodology all development team members (except for the facilitator) have an equal voice at the weekly status meeting in terms of feature selection.
• Facilitator/Management – Teams may have a facilitator, project manager, or personnel manager to run meetings and help focus the team. This role breaks voting ties, helps find ways for the team to work more efficiently, works with the architects to ensure proper feature breakdown (writing tickets, documenting, and artifacts production), works with the Product Owner to pre-sort the backlog and keep the board updated.
• Feature Architect – A member of the team leading the effort for a specific feature. The architect is the main point of contact for their feature and handle all questions, final reviews, design decisions, documentation, clearing blockers, and demonstrating the feature to the customer. This role is specific to each feature and an individual may be the feature architect on multiple features. Where two or more features intersect, the architects must coordinate together. If more than one team member is assigned to architect a large feature, the duties can be split between them, but one needs to be the central point-of-contact to "own" the feature.
• Customer Point of Contact (PoC) – The product owner or someone designated as the “owner” of the product design for an individual feature. This person is responsible for and capable of answering any questions of the feature, altering the design to deal with technical limitations, having UI designs created or altered, and generally able to solve any problems with the feature’s product design that is brought to them by the architect.
• Product Owner – The product owner represents the customer to the development team and the development team to the customer. This role communicates the product vision, is accountable for the product backlog, clarifies/defines feature descriptions, tracks User Stories and prioritizing product backlog items. The product owner coordinates with the customer to define the release backlog. If the product owner is a part of the development team (e.g. the functional lead), they must be detached from the wants/desires of the development team to ensure a fair representation of the customer's wishes.
• Support Team(s) – Various teams that include Quality Assurance (process compliance), HR, DevSecOps, and other support that assists the development team to keep working efficiently.

Meetings

Meetings are necessary to keep the team on track, bubble status upwards, or identify process improvements. While it is up to the team and the team’s management which meetings are required, they may include:

• Daily Stand-ups – Short daily meetings to highlight progress, blockers, or concerns.
• Weekly Status – Development team members, the facilitator, the product owner and select support team members (e.g. DevOps, or QA) meet to discuss how the previous week's work went, features that are going through architecture, any problems with getting features completed, any new/changed priorities from the customer, and to replenish the board.
• Backlog Grooming – The customer, product owner, and representatives of the development team meet to discuss priority of features and defects, flesh out the User Stories of prioritized features, and generally review the trajectory of the project.
• Monthly Retrospective – The team gathers to discuss the past month's work, features accomplished, how the work is going, and reviews team metrics.
• As-Needed – The team meets as necessary in break-out sessions and design meetings to discuss higher level system architecture, solve problems, and review architectural decisions.

Metrics

Feature Focused metrics are focused on features, as in all Agile methodologies, the top metrics are working product which can be seen by the number of features released and the number of defects created. The team can track what they need to ensure work is getting done in a reasonable timeframe (“reasonable” as defined by the team, product owner, and customer together). Other metrics should be tracked as trends to avoid comparing different teams inappropriately (e.g. the velocity of one team is never the same as another). The team can track such metrics as:

• Number of features per developer per month – This will work for teams that use smaller features (that don't require much breaking down) so that the team is able to continuously move features through the system.
• Technical ticket completion time – The standard Control Chart looking at the time between when a ticket is transitioned to status "In Progress" and enters the status "Testing".

Estimation

Some customers request an estimation of completion for either a feature or a set of features. This may facilitate the decision for which monthly tag to release or to even slightly postpone the monthly tag to capture a feature that is finishing its integration testing. If estimating is done, it should be at the feature level, cover all feature phases (architecting, work, and testing), be in terms of weeks, and should only be done when the team has no remaining concerns or questions about the feature. It should be clear to the customer that these estimations are not a time commitment (just estimates) and starts once the team put the feature into progress; not from the time the estimation is made.

Summary

The goal of Feature Focused is to assist the development team in making their work easier by attempting to better design the software through a detailed architectural process. This reduces the stress on the team by removing the need to problem solve while they are expected to be implementing solutions, remove potential blockers before they affect the work, give clearer path to success. Feature Focused helps management by giving a smoother transition through the development lifecycle without as many starting and stopping of work. Finally, Feature Focused is designed to help reduce experts becoming bottlenecks by elevating those experts to a supervisory role after they have resolved all of the design needs of their feature.