From 3a920289816eaefc94e05247fdbbf1e8eb020167 Mon Sep 17 00:00:00 2001 From: Jamie Strusz <5758031+allthedoll@users.noreply.github.com> Date: Fri, 23 Jan 2026 07:12:39 -0600 Subject: [PATCH] Revise project management roles and planning processes Updated project management documentation to clarify roles and responsibilities, including the addition of the Design Engineer role and adjustments to the RACI framework. Revised planning processes and meeting schedules for improved clarity. --- .../development/project-management.md | 393 ++++++++---------- 1 file changed, 173 insertions(+), 220 deletions(-) diff --git a/src/handbook/development/project-management.md b/src/handbook/development/project-management.md index 449be261f5..a5b336af4e 100644 --- a/src/handbook/development/project-management.md +++ b/src/handbook/development/project-management.md @@ -4,341 +4,294 @@ navTitle: Project Management # Project Management -This page details provides a comprehensive overview of the project management processes and procedures that guide product development at FlowFuse. +This page provides a comprehensive overview of the project management processes and procedures that guide product development at FlowFuse. ## Responsibilities -The three roles primarily involved in product planning and development at FlowFuse are the CTO, Engineering Manager, and Product Lead. The Product Lead advances strategic priorities and develops the product roadmap to achieve those priorities, the CTO determines technical feasibility and identifies the scope and dependencies of significant initiatives on the product roadmap, and the Engineering Manager assigns tasks to the engineering team and is responsible for delivering work on schedule. +The roles primarily involved in product planning and development at FlowFuse are **Product**, **CTO**, **Engineering Manager**, and **Design Engineer, Discovery & Initiatives**. -Following the RACI framework articulated elsewhere in the [Handbook](https://flowfuse.com/handbook/company/decisions/#projects), product responsibilities among the CTO, Engineering Manager, and Product Lead are: +- **Product** is responsible for defining product strategy, setting priorities, and shaping the roadmap to achieve desired outcomes. +- The **CTO** determines technical feasibility, architectural direction, and long-term technical strategy. +- The **Engineering Manager** plans execution, assigns work, and is accountable for delivery. +- The **Design Engineer, Discovery & Initiatives** (referred to as **Design Engineer** below) operates upstream, partnering closely with Product to explore problem spaces, shape solutions, and reduce uncertainty through design and technical discovery. -* Overall product roadmap and strategy: Product Lead is Responsible and Accountable, CTO is Consulted, Engineering Manager is Consulted. -* Articulating technical requirements and feasibility: Product Lead is Informed, CTO is Responsible and Accountable, Engineering Manager is Consulted and Informed -* Delivering work that is high quality and on schedule: Product Lead is Informed, CTO is Informed, Engineering Manager is Responsible and Accountable. +### Role Collaboration and Accountability -This means that on a day-to-day basis, the Product Lead and Engineering Manager work together to set the direction of product development and execute on a defined strategy that the CTO has helped to shape, with the Product Lead setting goals and defining initiatives, the Engineering Manager delivering the work, and the CTO serving as technical guide and sharing a product vision. +Following the RACI framework articulated elsewhere in the [Handbook](https://flowfuse.com/handbook/company/decisions/#projects), responsibilities are as follows: -The three meet every week in the Product Planning meeting to review progress of the current release and identify, define, discuss, and plan work for upcoming releases. +- **Overall product roadmap and strategy** + Product: Responsible & Accountable + CTO: Consulted + Engineering Manager: Consulted + Design Engineer: Consulted -## Product Planning Schedule - -In order to ensure that releases are able to deliver work according to the priorities laid out by the Product and Engineering teams, the four Product Planning meetings scheduled each release are organized as follows, with Week 1 being the first meeting that occurs just after a release has shipped. - -Week 1: The team discusses ongoing work and opportunities for future development. +- **Problem discovery, solution shaping, and early design** + Product: Responsible + Design Engineer: Responsible + CTO: Consulted + Engineering Manager: Consulted -Week 2: The PM has assigned a milestone to all epics and stories prioritized for the following milestone. For example, if it is week 2 of release 2.30, then the PM has completed this work in anticipation of release 2.31. +- **Technical feasibility and architectural direction** + CTO: Responsible & Accountable + Design Engineer: Consulted + Engineering Manager: Consulted + Product: Informed -Week 3: The EM has divided epics and stories into appropriate tasks, and with the CTO, assigned story points to them. The EM is also prepared with an estimation of how many story points can be delivered during the subsequent release, as these are influenced by individual engineer schedules, holidays, events, and etc. During this meeting, the PM's proposed release is discussed, and any issues with an oversized or undersized release are discussed and reprioritized by the PM, if necessary. +- **Delivery quality and schedule** + Engineering Manager: Responsible & Accountable + Product: Informed + CTO: Informed + Design Engineer: Informed -Week 4: The team prepares for the release that occurs during the same week. The EM reviews what was scheduled, what will ship, what will slip, and why. - -## Hierarchy +### How the Roles Work Together -As per our [Product Strategy](../product/strategy.md), our product is broken into three pillars - Build, Manage and Deploy. Within these pillars we have a collection of [Areas](../product/strategy.md#product-pillars). +On a day-to-day basis: -Beneath the areas, we then utilize the standard GitHub hierarchy of Epics, Stories, and Tasks. As such, the hierarchy is as follows: +- **Product** defines outcomes, prioritizes initiatives, and provides direction based on customer and business needs. +- The **Design Engineer** partners with Product to explore ideas, validate approaches, prototype solutions, and provide early technical and design context. +- The **CTO** provides architectural guidance, technical strategy, and long-term vision. +- The **Engineering Manager** translates defined work into executable tasks and delivers it with the engineering team. -- **Pillar**: One of three overarching values of the product - Build, Manage, Deploy. -- **Area**: A sub-section of a Pillar, representing a specific feature set or value offered to the customer within a pillar of the product. -- **Epic**: A significant feature or piece of work. It will typically have a number of Stories and/or Tasks associated with it that can be delivered iteratively. This may represent a single high level feature of the product, e.g. "Blueprints". -- **Story**: A user-oriented description of a feature. It should describe what a user should be able to do and identify the value that brings to the user. A story should be deliverable in a single release. -- **Task**: If we consider a Story as a user-centric view of a feature, the underlying tasks are the engineering-centric view of the same feature. This may also be a piece of work that isn't necessarily tied to a specific Epic or Story. For example, items related to technical debt or house-keeping chores. +Product, the Engineering Manager, the Design Engineer, and the CTO meet regularly in Product Planning to review progress, refine upcoming work, and ensure alignment before execution begins. -## Planning +## Product Planning Schedule -Our planning process is continuously evolving as we find the best way to accommodate both a growing team and an expanding set of requirements for how and what we deliver. We operate on a continuous delivery model, with iterations of two-weeks. +Each four-week release cycle includes four Product Planning meetings: -Whilst we deploy to FlowFuse Cloud on every merge to `main` branch, we conduct formal releases every four weeks. With this, we utilize GitHub milestones in order to track which items are planned for each release. The "Active Release" view provides a picture of all issues assigned to a given release, which is updated when a new release starts after our [retrospective](./releases/process.md#retrospective). +- **Week 1** + Review ongoing work and explore opportunities for future development. -### Cadence +- **Week 2** + Product assigns a milestone to all prioritized epics and stories for the upcoming release, informed by discovery and design work. -FlowFuse is continuously released to FlowFuse Cloud, and every four weeks, on a Thursday, it is packaged for users who are self-hosting FlowFuse. +- **Week 3** + The Engineering Manager breaks stories into tasks and validates feasibility with the CTO. The Design Engineer provides context from discovery, design exploration, and technical investigation. -### Prioritization +- **Week 4** + Final review of what is shipping, what is slipping, and why. -The planning process is continuous, allowing the engineering team to consistently release new functionalities. +## Hierarchy -This process covers the standard planning and prioritization process; bugs or minimal improvements are not part of this description. It is important to stay flexible, so this fast-lane approach for the described issues is possible and necessary. +As defined in our [Product Strategy](../product/strategy.md), FlowFuse is organized into three pillars: -Naturally there will be items that crop up unexpectedly and have to be dealt with pragmatically. For example, we may realize an item is needed for the current release that needs to be expedited through the process. We should remain flexible in how we work. +- Build +- Manage +- Deploy -#### Step 1 - Backlog prioritization and refinement -Based on customer feedback, input from the FlowFuse team, and all stakeholders, issues are continuously raised and prioritized [in our Backlog](#product-planning-board). +The planning hierarchy is: -#### Step 2 - Assignment to the To-Do section -Once an issue is refined, the PM continuously assigns issues to the [Development Board's](#development-board) `To-Do` Section. This is the first indication that this particular item is planned and will be the one of the next items for the `Up Next` section. It also signals the engineering and UX team to raise any open design or architectural clarifications if required. +- **Pillar** – One of the three product pillars +- **Area** – A specific product capability within a pillar +- **Epic** – A significant body of work delivered iteratively +- **Story** – A user-oriented feature deliverable within a release +- **Task** – A concrete unit of engineering work -This section should include a maximum of 40 [effort estimation points](#sizing-issues). +## Planning -#### Step 3 - Assignment to the Up Next section -This section is most relevant for the engineering team because it communicates the highest priority items that need to be worked on next. +FlowFuse operates on a **continuous delivery model** with **weekly sprints (Monday–Friday)**. -The PM is responsible for assigning issues to the "Up Next" section, while the Engineering Manager is responsible for directly assigning the issues in this section to an engineer, if there is a particular plan in place for an engineer to complete a given piece of work. +While we deploy to FlowFuse Cloud on every merge to `main`, we package formal releases every four weeks. GitHub milestones are used to track release scope. -The `Up Next` section should consistently contain sufficient items, ensuring that members of the engineering team can immediately transition to a new task once other issues have been [successfully developed](#defining-done). +### Cadence -#### Step 4 - Development +- Continuous delivery to FlowFuse Cloud +- Four-week release cadence for self-hosted users +- Sprint planning on Fridays +- Weekly refinement sessions -When an engineer is looking for their next item to work on, they should scan the "Up Next" section. If there are no items explicitly assigned to them already, they can choose their own desired work from that list. +### Prioritization -##### Mark "In Progress" +Planning is continuous and adaptive. While most work follows the standard planning flow, bugs and urgent issues may bypass parts of the process when necessary. -It is important that when a developer starts working on an issue, they move it to the `In Progress` section. This signals to the PM and the rest of the team that the issue is being worked on and is no longer available for others to pick up. It will also enable some of the automations we use for tracking progress. It is also desired that the engineer marks when a task is started, by recording the "Started" date on the issue's "Development" board item. +#### Step 1 – Backlog Prioritization and Refinement -##### Record "Expected" Date +Issues are raised and prioritized continuously on the Product Planning Board based on customer feedback, internal input, and strategic goals. -Where possible, developers should also provide a rough "Estimated" date as to when they expect the issue to be ready for review, i.e. development, testing and documentation has been finished. +Design discovery, technical exploration, and early prototyping led by the Design Engineer may inform prioritization and scope at this stage. -If this is not conducted, the Engineering Manager will assign an end date to the items based on the [effort estimation](#sizing-issues). +#### Step 2 – Assignment to To-Do -The estimated date should take into account the associated [size](#sizing-issues) of the issue and most importantly the developer's availability, and other workload commitments. +Refined issues are added to the Development Board’s `Todo` column. This signals upcoming work and invites design or architectural clarification. -## Issues +#### Step 3 – Assignment to Up Next -Issues are the building blocks of planning activities, helping the team to manage and prioritize work. +Product prioritizes issues into `Up Next`. +The Engineering Manager assigns ownership where appropriate. -### Types +This column should always contain enough work for engineers to move forward without waiting. -- **Epic**: a significant feature or piece of work. It will typically have a number of Stories and/or Tasks associated with it that can be delivered iteratively, and should be presented in the Epic as a [Tasklist](https://docs.github.com/en/issues/managing-your-tasks-with-tasklists/creating-a-tasklist). Typically, an Epic shouldn't be assigned a "Status"; instead, the subtasks describing the first, second, third iterations, which in turn are assigned respective status'. +#### Step 4 – Development -- **Story**: a *user-oriented* description of a feature. It should describe what a user should be able to do and identify the value that brings to the user. A story should be deliverable in a single release. +When ready for new work, engineers should select **tasks** from `Up Next`. -- **Task**: If we consider a Story as a user-centric view of a feature, the underlying tasks are the engineering-centric view of the same feature. This may also be a piece of work that isn't necessarily tied to a specific Epic or Story. For example, items related to technical debt or house-keeping chores. +While Stories provide user context, **tasks are the unit of execution** and should be what actively moves through the board. -- **Bugs**: issues that arise from errors, flaws, or unintended behavior in the existing code or system. Bugs negatively impact the user experience or the functionality of the software. They should be addressed and resolved by the development team, prioritized based on their severity, and included in the appropriate release for fixes. +##### Mark In Progress -- **Feature Requests**: suggestions or ideas submitted by users or stakeholders for new functionalities, enhancements, or improvements to the existing software or system. Feature requests should be evaluated, prioritized, and potentially incorporated into the product roadmap, often being transformed into Epics or Stories for implementation in future releases. +When starting work, engineers must move the **task** to `In Progress` and record the Started date. This signals ownership and enables progress tracking. -Whenever an issue is raised, it will be reviewed by the Product Manager / Engineering Manager and added -to the Product Planning Board for prioritization and planning. The exception to this are -tasks/bugs related to work already in progress and that need to be addressed in -the current milestone. They should be added to the Development Board and current -milestone directly. +##### Record Expected Date -#### Headline Features +Engineers should provide a rough expected completion date. +If not provided, the Engineering Manager will assign one based on estimates and availability. -We label some items as `headline`. These are items we want to highlight in the ["changelog"](#changelog) and further -announcements and should clearly describe the value they bring to our users. +## Issues -We provide the ["Headlines" view](https://github.com/orgs/FlowFuse/projects/1/views/39) on our GitHub project boards to track these items on a release-by-release basis so that the customer team has a clearer view on what new content can be discussed in socials, etc. +Issues are the core planning unit. -#### Changelog +### Types -We produce changelog entries for new features and changes that are of interest to users. These are typically short highlight articles that let users know what we have added or improved in the product and can be found at https://flowfuse.com/changelog/ +- **Epic** – Large initiatives composed of multiple stories or tasks +- **Story** – User-facing value delivered within a release +- **Task** – A concrete engineering activity +- **Bug** – Defects impacting functionality or user experience +- **Feature Request** – Suggested enhancements or new capabilities -ChangeLog entries are created via PR to the [website](https://github.com/FlowFuse/website/tree/main/src/changelog) repository. +Issues are reviewed by Product and Engineering and routed to the appropriate board. -##### Changelog Entry Format +### Headline Features -Each changelog entry should include frontmatter with the following structure: +Items labeled `headline` are highlighted in release communications and changelogs. -```yaml ---- -title: "Feature Title" -description: "Brief description of the feature or change" -date: 2025-06-11 12:00:00.0 -authors: ["author-handle"] -tags: - - changelog -issues: - - "https://github.com/FlowFuse/device-agent/issues/185" - - "#1234" - - "567" ---- -``` +### Changelog -**GitHub Issues Integration**: You can now link related GitHub issues to changelog entries using the `issues` array in the frontmatter. This helps customers and internal stakeholders easily access the underlying GitHub discussions and technical details. The system supports: +Changelog entries are created via PRs to the website repository and include links to related GitHub issues. -- **Full GitHub URLs**: `"https://github.com/FlowFuse/device-agent/issues/185"` -- **Short form for main FlowFuse repo**: `"#1234"` (automatically links to FlowFuse/flowfuse) -- **Issue numbers only**: `"567"` (automatically links to FlowFuse/flowfuse) +## Sizing Issues -The issues will be displayed as clickable links with GitHub icons on both the changelog listing page and individual changelog posts. +FlowFuse estimates work using **time-based estimates**, not story points. -### Sizing Issues +Our goal is clarity, not precision: -To more accurately understand which tasks can be scheduled without overloading our team, everyone conducts an initial, high-level analysis when creating an issue to assign weight estimates. We recognize that these estimates might not be precise. If the person who creates an issue cannot provide an estimate, any FlowFuse team member is welcome to contribute one. +- Keep work small and flowing +- Surface risk early +- Avoid large, opaque tasks -If a developer, who is an expert in a field, wants to change an estimation, they are encouraged to do so. There is no blame for "wrong" estimation; we all have to work together to achieve good planning. It is better to have a rough estimation than no estimation at all. The final decision on estimations in general lies with the CTO. +### Core Principles -If a larger number of not estimated tasks need to be estimated, e.g. for a complex epic, the CTO and PM can initiate a [Planning Poker](https://en.wikipedia.org/wiki/Planning_poker) session. +- **Tasks and subtasks must be 4 hours or less** +- Anything larger must be broken down +- Estimates are expressed in time +- Estimates evolve as understanding improves -Issue sizes are assigned in two stages: +### How Estimation Works -1. The Product Manager will review high-level Epics and Issues and assign a size based on the broad complexity of the issue. This is done via a label on the issue, and follows the standard planning poker story point sizes. -2. When an item is moved into the Development Board, the Engineering Manager will review the issue and assign a size based on the effort required to complete the issue. This is done via the "Size" field on the [Development Board](https://github.com/orgs/FlowFuse/projects/1). +#### Initial Estimation -Size labels are as follows: +A rough time estimate should be provided during issue creation or refinement. This includes implementation, testing, and documentation. -- **XS - 1**: Extra Small ~ Less than a day of development effort -- **S - 2**: Small ~ 1 day days of development effort -- **M - 3**: Medium ~ 2 or 3 days of development effort -- **L - 5**: Large ~ 3-5 days of development effort -- **XL - 8**: Extra Large ~ 1-2 weeks of development effort -- **XXL - 13**: Extra Large ~ More than 2 weeks of development effort +#### Refinement and Breakdown -"Days of development effort" here would assume this was the only task the developer was working on, which is rarely the case. The actual time to complete a task will be longer than the number of days, or sizing, assigned to it. +Weekly refinement sessions are used to: -There are two crucial elements to consider when determining an issue's weight: +- Break stories into tasks +- Clarify scope and acceptance criteria +- Discuss technical approaches +- Ensure tasks are ≤ 4 hours -- **Scope**: The amount of work pertains to the anticipated extent of modifications to the codebase. A minor adjustment might only require a single alteration in a single file, whereas a more extensive modification could necessitate multiple alterations across numerous files and sections of our codebase. -- **Complexity:** Complexity can be divided into two components in practice: the degree to which the problem is understood and the expected level of problem-solving challenges. +The Design Engineer may contribute discovery findings or technical context to reduce uncertainty. -Epics do not necessarily need an estimation, as long as all sub-issues have estimations, Epics are the sum of all subtasks, as a result, it is possible to handle epics larger than XXL. Be sure to not double-book the sizing. If a Story has a sizing, it's children tasks do not need a sizing too. Points are best served at the Story level, however, if you feel the Story is too large, you can break it down into smaller Tasks, and size appropriately there. +#### Sprint Planning -#### Measuring Burn Rate +Sprint planning happens weekly on Fridays. Work is selected based on capacity and availability. -With the "Size" field on the [Development Board](https://github.com/orgs/FlowFuse/projects/1) we can calculate the "burn rate" of the team, and use [GitHub's Insights](https://github.com/orgs/FlowFuse/projects/1/insights/11) to track the burn rate over time. +### Task Sizing Guidelines -![Burn Rate from the 2.15 Milestone, showing a sum of the story points scheduled and delivered over time](./images/pm-burn-rate.png){data-zoomable} -_Burn Rate from the 2.15 Milestone, showing a sum of the story points scheduled and delivered over time_ +- **≤ 4 hours** → acceptable +- **> 4 hours** → break it down -We can use these Burn Charts to measure the delivery velocity, i.e. the number of story points we expect the Engineering team to deliver in a given time frame. When planning future releases, considerations should be made for planned absences and events, such that the amount of work scheduled is sustainable. +Stories may span multiple days, but **tasks must remain small and well-defined**. -### What makes a good issue? +### Ownership and Adjustments -A good issue is one that is clear in it's scope, key tasks to be completed, and the value accomplished through it's completion, e.g. security flaw resolved, new feature added and the benefit that feature offers. +- Engineers may re-estimate or split tasks as needed +- Tasks that grow should be split, not stretched +- The Engineering Manager helps rebalance work -Some particular considerations to keep in mind: +## What makes a good issue? -#### Defining a Story +A good issue is clear in scope, intent, and value. -The best "Stories" are those that follow this structure: +### Defining a Story -> As a _[type of user]_, I want to _[do something]_, so that they can _[achieve some goal]_. +Stories should follow: -Note how this is user-centric and focuses on the value that the feature brings to the user. +> As a _[type of user]_, I want to _[do something]_, so that _[value]_. -#### Breaking a Story into Tasks +### What makes a good Task? -If we consider a story as a user-centric view of a feature, the underlying tasks are the engineering-centric view of the same feature. +A good task is small, explicit, and independently completable. -Well structured stories, when it comes to implementation, can often be broken down into clearer tasks. A trivial breakdown could be a separation of the UI design work, UI implementation, and backend implementation. +A task should: -When a member of the team is assigned a Story, they may be comfortable handling the full piece of work themselves, which is fine, and they can continue as such. +- Be ≤ 4 hours +- Have a clear outcome +- Be independently startable +- Make progress visible -It is also fine to break it down into tasks and assign them to different people, if you feel others' skills are better suited to certain parts of the work. An example to consider is a piece of work that requires the following: +**Good examples** -- API Changes -- Database Migration -- Frontend Development +- “Add validation for device name length” +- “Wire feature flag for metrics panel” +- “Add unit tests for token refresh” -_Engineer A_ may have been assigned the parent Story, and be comfortable doing the first two parts, but feel a colleague, _Engineer B_ is better suited to the front-end work. Engineers should feel empowered to use common sense here, and break the work down as they see fit, asking for assistance from their colleagues and collaborating to get the work done. +**Avoid** -If you're unsure, or uncomfortable with a piece of assigned work please speak to the Engineering Manager or Product Manager. +- “Implement backend” +- “Refactor auth” +- “Polish UI” +If a task feels vague or hard to estimate, it should be split. ## Project Boards -We use two project boards to plan and track our work. +We use two GitHub project boards: - - [Product Planning Board](https://github.com/orgs/FlowFuse/projects/3/views/1) - - [Development Board](https://github.com/orgs/FlowFuse/projects/1/views/1) +- [Product Planning Board](https://github.com/orgs/FlowFuse/projects/3/views/1) +- [Development Board](https://github.com/orgs/FlowFuse/projects/1/views/1) ### Product Planning Board -[This board](https://github.com/orgs/FlowFuse/projects/3/views/1) is maintained -by the Product Manager (PM) and CTO. It is the main entry point for all issues. Longer term planning and strategy is defined here. Each item on the - -#### Area (for Epics) - -As per our [Product Strategy](../product/strategy.md), our product is broken into three pillars - Build, Manage and Deploy. Within these pillars we have a collection of [Areas](../product/strategy.md#product-pillars). - -When we create Epics in GitHub, we assign them to an Area. This helps us to understand where the work fits into our overall product strategy, and what fundamental area of the product will be improved by the work. - -You can see a breakdown of all Epics by Area & Status [here](https://github.com/orgs/FlowFuse/projects/3/views/9) - -#### Status (for all other issues) - -Stories and Tasks on this board are put into one of the following states to indicate their priority in the backlog, they can move up or down the priority depending on business needs. - - - `No Status` - This is where all new items initially land so that they can be appropriately triaged and assigned by the PM and CTO - - `Started` - Some work in this has been started, in the case of Epics, it may be a reflection that not all work here is planned to be completed though. - - `Next` - These are items which we should be targeting for the next milestone to be planned, We plan milestones 2-3 iterations ahead so this time frame will typically be 2-3 months. - - `Short` - These are items in the 3-6 month time frame, Often these items will get pulled into a milestone from this point depending on capacity. - - `Medium` - These are items that are in the 6-12 month time frame. - - `Long` - This is the long term horizon, items that we know we will want to do one day but at the moment are long term goals, typically this could be 12 months away or more. - - `Icebox` - These are items that we do not currently see a clear plan for in building into FlowFuse, however, may be important to keep in mind for the future. - - `Support & Under Review` - Customers often ask questions via GitHub issues. From these questions, new insightful requirements sometimes arise. Initially, to clarify the situation with the users, issues belong to this category. - - `Closed` - All closed items are assigned to this section or being removed from th backlog. -As items move up the list and get closer to Next we should have a greater understanding of what the detail and demand is for that feature. This is an iterative approach and as we gain understanding on an item we will use that information to aid in reviewing its position on the board. - - A continuous review is held by the PM to keep the backlog in order - triaging new items that have been raised and not yet added to the backlog, and reflecting on changing priorities and requirements. +Maintained by Product and the CTO. Used for long-term planning and prioritization. ### Development Board -Any item on the Development board detail in-action items, or items planned for the immediate future (<4 weeks). It provides multiple views that are useful to get a clear picture on our active, and short-term planned items. - -#### Activity Tracker - -![Development Board - Activity Tracker View](../images/project-management/board-timeline.png){data-zoomable} - -The [Activity Tracker](https://github.com/orgs/FlowFuse/projects/1/views/33) is -used to plan and track the work. +Tracks active and near-term work. -The board has the following states: +#### States - - `Todo` - items queued to go into "Up Next" once there is availability - - `Up Next` - items that should be picked up next - - `In Design` - items being designed, whether that is UX/UI design or engineering design - - `In Progress` - items being developed - - `Review` - items that are ready to be reviewed (PR open & [feature demo](#feature-demos) created) - - `Done` - items that are [Done](#defining-done) +- Todo +- Up Next +- In Design +- In Progress +- Review +- Done -##### In Design Deliverables +##### In Design -Both UX/UI work and engineering work can be "In Design". For both instances there should still be defined deliverables. - -It is important to use Design as a tool for conversation, verification, or to ensure engineers and the wider team are on the same page, but it should rarely be a blocker given our [Bias for Action](../company/values/#🔁-iterative-improvement) value. - -- **UI/UX Work:** This is generally work in Figma for product, website or the components library. Deliverables should be well-defined as an MVP prototype, or at least enough for engineering to get started, on which we can iterate. -- **Engineering:** Questions that need answers should be formulated up front, and answered as the deliverable. Questions around what technology to use, how to scope down the feature set, and how to deliver the results -are thus required before the design sprint start. +Design work (UX or engineering) must have clear deliverables and should not block progress unnecessarily. ##### Defining Done -An item should only be marked as 'Done' on the Development board when the following -criteria are met: +An item is Done when: - - All related code changes have been merged - - Suitable unit/system level tests have been added - - Documentation has been updated - - Acceptance criteria identified in the Story have been met - - Feature Demo +- Code is merged +- Tests are added +- Documentation is updated +- Acceptance criteria are met +- A feature demo is recorded ##### Feature Demos -Part of finishing an item is being able to demonstrate it in action. This allows -others to see it in action, generate material for the release announcement and -help identify any gaps or places for improvement. - -Each feature demo is recorded by the developer responsible for the feature, detailing its functions and operations. If problems, challenges, or improvement ideas arise during the review of the demo, everyone is encouraged to post a comment under the video within the Slack channel. Additionally, a corresponding GitHub issue should be opened to track and prioritize these points for further discussion and action. - -Demos must be done in good time and as early as possible to allow for any follow-up action. - -Demos should consist of: - - - A short (< 5 minute where possible) screen capture walk through of the feature with commentary. - - It should cover the feature from a users perspective - what value do they get from it. - - The video should be uploaded to, or linked to, in the relevant issue. - - A link should be posted to the `#feature-demos` channel in slack. This will allow the whole team to be notified of the demo without having to subscribe to every issue comment. - -For some features, it may be necessary to create multiple demos of different aspects. +Each completed feature includes a short demo video shared in `#feature-demos` with a link in the issue. #### Timeline -![Development Board - Timeline View](../images/project-management/board-timeline.png){data-zoomable} - -The [Timeline](https://github.com/orgs/FlowFuse/projects/1/views/49) view utilizes the "Started" and "Expected" dates to give a visual representation active items that each member of the team is working on, as well as a clear picture of when they are expected to be completed. +The Timeline view uses Started and Expected dates to visualize near-term execution rather than long-range prediction. ## Engineering Throughput -Engineering throughput is a measure of how much value we're able to deliver to our customers. It's calculated by summing the total number of Pull Requests merged in a given time frame across the following repositories: - -- [FlowFuse](https://github.com/flowfuse/flowfuse) -- [Node-RED](https://github.com/node-red/node-red) -- [Node-RED Dashboard 2.0](https://github.com/flowfuse/node-red-dashboard) -- [Node-RED Launcher](https://github.com/flowfuse/node-red-launcher) -- [Blueprint Library](https://github.com/flowfuse/blueprint-library) +Engineering throughput measures delivered value and is tracked via merged PRs across core repositories. -An interactive Dashboard for these metrics, and a breakdown of the specifics issues and Pull Requests involved can be found [here](https://github-stats.flowfuse.cloud/dashboard/analysis). +An interactive dashboard is available at: +https://github-stats.flowfuse.cloud/dashboard/analysis