Abstract

Popular methodologies tend to revolve around larger objects like User Stories, while development teams tend to prefer breaking those large objects down into smaller, and more technical, work tickets. This is often done through a research, architectural, or breakdown process where the team figures out the best way to implement the overall request. When this is done unique problems arise with these methodologies. The team may size the architectural/breakdown process to fit into the acceptable timebox, pause the team’s cadence while the architecting is done, or move the breakdown process to a specialized group; out of the team’s control.

This proposed Feature Focused methodology attempts to solve the breakdown process by incorporating it, and the work tickets it generates, into the normal processes of the team. The creation of work tickets is highlighted, and all tickets remain attached to their parent feature so that the group of tickets moves through the process together.

The Feature Focused methodology attempts to adhere to the Lean principles and assumes a pre-defined list of features by the customer. It is more focused on the conversion of features into development work than defining good features.

Features as the Base Unit

A feature encapsulates a distinct element of functionality. In software this functionality normally has UI, back-end, and database parts. It is large enough to warrant multiple tickets for implementation and distinct enough to fully test. Features may contain multiple requirements and may be expressed in terms of user stories.

Ticket Types

Feature Focused requires three (3) types of tickets to function appropriately: Feature, Defect, and Technical.

Feature tickets hold the overall information about the feature. It may contain user stories, related requirements, 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. Feature tickets group the technical tickets, have their status updated for the development life cycle, and receive testing results.

Bugs found during testing and non-conformance found after features are released receive Defect tickets. Defects found during the testing of a feature are included in the feature’s work. While 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 receiving integration testing before being merged into the source code.

Technical tickets are those produced by the breaking down and architecting of a feature. 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. 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 flows appropriately without major blockages or interruptions. For example, ticket A may be blocked by B and C, so the order of the tickets would need to be B, C, A.

Architecting Technical Tickets

The main problem Feature Focus is attempting to solve is the disconnect between larger objects like features, and the smaller technical tickets engineers prefer to work with. This process of breaking down features, or technically architecting the solution, has some standard inputs, work, and outputs.

The input of the architecting process is everything the team feels they need to ensure the feature can be successfully accomplished. These inputs serve as the basis of knowledge and customer’s understanding of the feature. 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 obfuscation") or implicitly inferred from other requirements or user stories (such as the requirement of "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.
• Declared deliverables – Along with the scope the deliverable should also be clearly defined so the team knows when to stop.
• 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 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.

Once the inputs have been double checked and the team accepts the ticket (see the workflow example and feature selection sections below) the architect assigned to the feature can begin the actions needed to successfully create the technical tickets.

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 PoC. Once the full scope of the work is understood the requirements can be documented and "set in stone".
2. Identify components to update – Both as a first pass and later as a refinement, what areas of the system are likely to be affected should be identified and well understood.
3. Research current code related to the feature – A more in-depth look at the components, the architect should be aware of how the affected components currently function.
4. Design the UI & potential edge cases with the PoC – An iterative process where the architect works with the customer PoC to ensure any UI directions is what the customer wants and to review potential edge cases or error handling is correct. 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 not touched by the new feature but may be affected by it. The peripheral areas are important to capture in order to squash 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 and that all questions have been answered.

The goal of architecting is to generate technical knowledge about the feature, the solution of how it will be implemented, and technical tickets to execute the solution. 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 large/encapsulated/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.

Roles

Feature Focus reduces roles into several main categories:

• Customer/Sponsor – The person(s) or group(s) that owns the project and/or has approval to provide high-level feature prioritization. An example is a business analyst group assigned to the project to determine which features have a higher monetary impact once released.
• Development Team – Referred going forward 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 – Teams may elect, or be assigned, a facilitator to run meetings and help focus the team. This facilitator breaks voting ties, helps motivate the team to work 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, and generally attempts to perform the role of an embedded project manager within the development team.
• 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 all questions, final reviews, design decisions, documentation, and demoing the feature to the customer fall to this individual. This role is specific to each feature. 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 (POC) to "own" the feature. "Team architects break down a feature into technical tickets and then acts as the lead of that feature for any questions, feedback, decisions, and guidance required."
• 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 higher level management, Quality Assurance (process compliance), HR, DevOps, and other support that assists the development team to keep working efficiently.

Board

The Feature Focused board is split into multiple columns. 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”).

Work flows from right to left, keeping the more important work to the left of the less important work. While this flow is backwards from most styles, the majority of languages ready from left to right so this keeps the most important items at the top-left side, and first to be seen. 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 until it is completed and cleared off the board.

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. Like Kanban’s WIP limits, the team should restrict the number of features the team can work on simultaneously to promote getting the features completed. These In-Progress features are prioritized highest importance on the left and least important on the right.

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 have been prioritized and are ready to be researched/architected. Finally, the right most column is the Backlog group containing everything else that is of any priority.

Workflow Example

Examples here on are using a physical board with sticky notes. Jira and Asana implementations are found in their respective sections. Blue sticky notes are used for features, pink sticky notes are used for defects, green sticky notes are used for technical tickets, and red sticky tabs/strips are used for problem flags.

At the beginning of implementation, a team of six (6) developers will find a board of Critical Defects, two (2) empty In-Progress Features columns, an empty Approved Defects column, and a Backlog column full of blue feature tickets (A through H) and pink defect tickets (1 through 20). The team has met with their product owner and customer and holds a list of priorities. The top priority for the customer is A (e.g. a new automated report) and the top priority for the development team is C (e.g. a new socket layer). At the weekly status meeting, the team discusses priorities and work. The team then moves the blue and pick tickets to their assigned locations: features A & C are put at the top of the In-Progress Features columns, defect tickets 1, 2, 4, 5,7 are placed in the Approved Defects column, and features B & D are placed in the Prioritized Features columns. As a group the team estimates feature A will take roughly two (2) weeks and feature C will take roughly a week (this includes breakdown).

The team now has what features to work on, but there are no technical tickets yet. John and Paul begin deconstructing feature A, Aretha begin deconstructing feature C, while Ringo, George, and Tina work on approved defect tickets.

Later that first day Aretha has finished deconstructing feature C into five (5) technical tickets, putting them on the board in the vertical order they should be worked on within the feature C column, and creating the feature branch in Git. She begins to work on the first ticket, ensuring that she creates her ticket branch from the feature branch.

Later that week, John and Paul finish putting their tickets on the board and take tickets of their own. As Ringo, George, Tina, and Aretha finish their tickets (meaning the work has gone through code review and is in Testing status) they pick up the next tickets available; first from the feature A column, then the next feature, and finally the approved defects. If the next open ticket is blocked by something the developer cannot actively resolve (e.g. a dependency on another ticket someone else is working on), the developer moves to the next ticket. Contrariwise, if a ticket blockage is something that can be resolved, the developer should attempt to do so as part of that ticket.

On the second week the team completed Feature A’s development work. John and Aretha volunteer to test it. They pull the main develop branch into the feature branch, run the automated tests, work through the manual test, and perform some exploratory testing. The team found a defect, so they created a new green ticket and placed in the Feature A column. Once the team fixes the defect and completed the remaining testing, the entire feature gets merged into the main/develop branch (using GitFlow nomenclature). The architect finally removes the feature ticket (with all the green technical tickets) from the board and moves feature C to the, now free, column.

At the next weekly status meeting the team reviews their work and moves feature B to the free column in the In-Progress Feature section; pushing Feature C into the primary spot. Tina volunteers to deconstruct it while the other members finish feature C. The team fills the free column now available in the Prioritized Features column with feature F and replenishes the Approved Defects column.

After a month of work, the team convenes for a retrospective. They discuss topics such as ticket creation, feature architecture, prioritization, recent defects, etc. At the end they tag the Develop branch with the month-year to signify it is ready for release. At another meeting, the team product owner and development representatives demo the month’s work to the customer, showcasing each completed feature.

After a few months of this cycle, the customer and product owner decide they would like a release. The team creates a release branch at the last month-year tag and that build is sent to customer acceptance testing; the development team continues as normal.

Feature Selection

The customer, product owner, and representation from the development team perform backlog grooming meetings to assess which features and defects are approved for work; as well as their priorities. This conversation should include both the customer’s priorities and development’s priorities to better understand the needs of both.

The development team then makes the final decision (with the guidance of the product owner) which features to commit to when putting them in the In-Progress column (pulling them across the “Line of Commitment”). If the team does not select the features in the customer chosen priority, the product owner must document their rational, updated the customer, and attempt to resolve it at the next backlog grooming meeting or during an as-needed meeting (whichever is appropriate for the situation). Some reasons the development team may not approve of a high priority feature:

• 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.
• 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 and worked on.

Blockers

Blockers come in two main forms; internal and external dependencies. Internal dependencies are blockers the team has control over resolving. They receive tickets and ranked along with other technical tickets within the feature to ensure an efficient workflow continues. The team has little to no control over external dependencies and need to be identified, researched, and potentially resolved, before committing to the feature.

Critical Defects

Defects that are critical in nature 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 do not belong in the critical defect column. Features, being a larger development effort that requires design considerations, receive the appropriate time and thought to produce defect-free code.

Source Control

The following nomenclature identifies the branching strategy used in Git (and can apply to other source control products).

• Master – The gold master branch of code is untouched by development changes. Only code that has passed customer acceptance testing and is released gets merge into this branch.
• Develop – This is the branch of code that holds completed features and fixed non-conformances that ready for acceptance testing. Only features and approved defects that have passed integration testing get merged into this branch. At the end of each month the team tags this branch with the month-year (e.g. "April-2019"). Release branches get created from the tag locations.
• Release – This type of branch uses the name of the release for the branch name (e.g. "2019.2"). It is a quarantined environment for acceptance testing so that other features or non-release defects that continue to be merged into Develop are not added to the release. Defects found during acceptance testing are merged into this branch and then develop. Patch and Hotfix branches are release branches that branch off other release branch (e.g. "2019.2.1" is branched off of release branch "2019.2")
• Feature – This type of branch is named after the feature number. It is where all development updates for that feature are merged and the entire feature is tested against.
• Ticket – Each technical ticket (either within a feature or a defect) receives its own ticket branch. Code reviews are performed on these branches before being merged into their higher-level branch (either feature, release, or develop as appropriate).

Note that all merges should have pull requests so that everything can be double checked before merging into the higher-level branches. Throughout the life of a feature branch Develop should be pulled and merged into; updating the feature code and ensuring smooth transition back to Develop. If the team has repeated merge conflicts while merging feature branches into develop, this means the feature tickets are too large or the team is attempting to add too many features at the same time. This is fixed by reducing In-Progress column count and reviewing the team’s definition of a feature (i.e. can a feature be broken into multiple segments to work on sequentially).

Testing

Testing comes in the forms of unit tests, functional tests, integration testing, and acceptance testing. Unit tests (testing inputs and outputs of class methods) and functional tests (testing of classes or modules, but not necessarily integrated within the entire eco-system) should be done before technical and defect tickets are put up for peer review. Integration testing is performed on feature branches and, only upon successful completion of integration testing, are features allowed to be merged in develop. Acceptance testing (also known as customer acceptance testing, site acceptance testing, or validation testing) is performed once a release package has been created and delivered to the customer.

For integration testing, it is the architect’s duty to ensure all areas of the system potentially impacted by the new feature are appropriately tested. This includes merging the Develop branch back into the feature branch to receive any changes to the code base since the feature’s work started. Any manual test cases that need to be made should be either created by the feature’s architect(s) or reviewed by the feature architects after other team members update/create them. This is to ensure consistency with their vision and alignment to the User Stories. If automated integration testing is used (highly encouraged where possible), the architect(s) review that enough tests (both positive and negative) were created.

The architect and another volunteer (or more, depending on how many test cases are needed) perform the feature’s integration testing and attach any completed manual tests to the feature ticket. If an integration test fails, it is still uploaded to the feature ticket and new defect tickets are made within the feature. These defects should be completed, and the failed test cases should be retested, before integration testing is complete.

After all testing is done the architect makes a final review of the code in a pull request, merges it into the develop branch, reviews the feature documentation for any changes that had not been captured, and updates the release feature list.

The goal of testing is to ensure everything in the develop branch has been appropriately tested.

Releases

Release packages are created on a monthly basis, except for in emergency situations when a patch or hotfix is needed. When the Customer/Sponsor decides a release is warranted, a release branch is created from the last monthly tag and the build from that branch is put into acceptance testing (as all integration testing has been completed on everything that is within the develop branch).

Documentation

Beyond the standard code comments, ticketing system, and meeting minutes, Feature Focused teams should maintain a list of supporting documents to ensure smooth transitions of the development life cycle.

• 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 must 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.

Meetings

• 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.

Extra Thoughts & Alterations

As the team worked through Feature Focused, a couple of alterations were considered. These didn’t seem to change the overall goal and might be useful for some team to visualize the work.

Technical Ticket Workflow

In project management systems (such as Jira or Trello) it is recommended to use a simplistic workflow such as Open, In Progress, Peer Review, Testing, Ready for Release, Closed with no “On Hold”, or “Blocked” status. A blocked technical ticket should get flagged for higher visibility, communicated throughout the team, and a solution should be found immediately. Peer Review status is used to either perform code reviews (however the team wishes to handle those) or review other work such as documentation. Ready for Release is for when the feature is merged back into the main development branch, while Closed is used for when tickets, in a release, are approved for deployment. Users may push tickets forward or backwards in the order given and after Ready for Release or Closed a ticket may be reopened to put it back in the Open status.

Metrics

Feature Focused metrics are focused on features, as in all Agile methodologies, the top metrics are working product and number of features released. 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".

Monthly Tags

The purpose of the monthly tag is to have a stable milestone in which to create releases from and have the team review their current progress. It helps Customers and Sponsors avoid releasing larger feature sets by conforming to a cadence of deliveries. An alteration to this is creating feature set tags or releasing mid-month once a set of features are completed. The team should still only promote finished features (including integration testing) and tested defect fixes into the develop branch.

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.

Order of In-Progress Columns

Some teams may find that the order of the features within the In-Progress column set may not accurately reflect the priorities of the team if one of the features is completely blocked. They may find it helpful to reorder the columns. For example, with features A and C both being worked on (in that order), if A becomes completely blocked, why not switch them to C then A? This is fine if ALL remaining work in A is blocked. If it is not, then those technical tickets that can be worked on should be ranked higher and picked up by the next available developer.

The team should take caution to remember that both of those features have passed the “Line of Commitment” and need to be finished in a reasonable amount of time. Blockers of this nature should have been discovered prior to committing to the feature, the nature of the blocker should be discussed with the customer, and steps should be taken to prevent this from occurring again.