Based on the previous experience of the framework team—which follows a company-wide approach for column definitions, time management, and sprint organization—this document proposes several improvements. Most of the methods described here are already used by Agile Scrum teams of around 5–10 members, which aligns well with our current project goals.
Columns:
- To Do – Newly created items or backlog items ready to be worked on.
- In Progress – Development or active work is happening.
- Review – Code review or peer review in progress.
- QA – Tester verifies front-end and back-end functionality against acceptance criteria.
- Done – Completed and ready for deployment to integration.
Note: Swimlanes on the board should correspond to ticket statuses, ensuring that tasks in the "QA" swimlane cannot be marked as "In Progress" simultaneously. This restriction helps maintain process clarity and prevents overlapping states.
Rationale: By reducing the columns, we eliminate confusion and clutter. Each state has a clear purpose: planning and tracking become easier, and it’s simpler to see who owns each task at any given time.
One Story, One Flow
-
Currently, separate tickets for development vs. QA create significant overhead and information gaps. Instead, keep development and QA tasks under the same user story (using sub-tasks only if needed for clarity).
-
Assign the tester to perform front-end and back-end checks once development is “Review”-complete. Why Eliminate Separate QA Tickets
-
Reduces administrative work: No need to clone or migrate information.
-
Maintains visibility: All updates, attachments, and context stay together.
-
Improves communication: Developers and testers collaborate on the same ticket, ensuring consistent requirements and acceptance criteria.
Story Points for Complexity
-
Adopt story points (or a similar relative sizing) as the primary metric for capacity planning. This helps the team gauge complexity rather than forcing inaccurate, hour-based estimates.
-
Over time, track your velocity (average story points delivered per sprint) to forecast how much the team can handle. Hours Are Not Always Accurate
-
While management might desire precise timelines, hours tend to be guesswork, especially for a new team.
-
Provide ranges or use the velocity trend after a few sprints to offer approximate timelines.
-
Rationale: Combining story points and hours often creates conflicting data, leading to confusion about “true” progress and completion dates. Sticking to one primary measure improves alignment and simplifies reporting.
** Define Acceptance Criteria and DoD (Definition of Done)**
-
Ensure every story has clear acceptance criteria. The QA knows exactly what to test, and the developer knows what must be delivered before moving a story to Review.
-
Align on the Definition of Done (DoD) with the BA, Designer, and Tester upfront. This includes compliance with the basic design, functional tests, and relevant documentation updates. Minimize Discrepancies Between Design and Implementation
-
Encourage early design reviews: The Designer should share mockups or wireframes in smaller increments.
-
Conduct quick, asynchronous check-ins to confirm the design matches the story requirements.
Given the tight deadlines, pursuing perfection could result in missed or unmanageable timelines. By simplifying the design process and conducting early reviews and wireframing sessions before finalizing the UI, the team can manage time more effectively and set clear priorities.
To avoid future misunderstandings, it is vital to create documentation detailing how each component should interact before moving any task into active development. This approach will promote consistency, reduce rework, and ensure everyone shares the same understanding of the system’s architecture and requirements.