Agile - cilerler/cilerler.github.io GitHub Wiki

Development Framework

Roles

Teams

Values

Lifecycle

Midnight Sailboat Retrospective Template

Common Pitfalls and Anti-Patterns in Software Development

Premature Involvement

Involving DEV when the BUSINESS team has not reached consensus.

Requirements Churn

Changing requirements or acceptance criteria mid-project. Once work begins, changes shouldn't be allowed—new features or tweaks should wait until the end and shouldn't affect the original timeline.

Context Switching

Rapidly shifting focus between multiple tasks or tickets. Once a sprint begins, unless there's a production failure, new tasks should wait until the next sprint.

Scope Creep

Mixing new issues into the same ticket. If a ticket is for one problem, any new (related or unrelated) issue belongs in a new ticket.

Bug Inflation

Labeling most of the issues as a "BUG". There are better categories (FEATURE, OPTIMIZATION, ENHANCEMENT, TASK). "BUG" should be reserved for actual coding errors caused by developer mistakes, reflecting work quality.

Ignoring Technical Debt

Avoiding necessary refactors leads to accumulating issues that become costlier to fix later.

Ticket Misuse

Creating or updating tickets without objectives, reproduction steps, acceptance criteria, business context, full-window screenshots, meaningful updates, or correct labels misguides priorities, fuels confusion, and sparks endless back-and-forth.

[!TIP] A well-written ticket should include all necessary information so a developer can pick it up and finish it without asking questions, even at 3 AM.

Opinionated Approach to Story Point Calculation

[!CAUTION] As a developer, it's fine to maintain your own mental mapping between hours and story points, but never make it public. Keeping this internal helps you estimate realistically without introducing false precision, setting misleading expectations, or inviting manipulation of metrics. This way, the team focuses on relative effort, velocity accounts for inevitable variations, and managers are prevented from reverse-engineering points into rigid time commitments.

The following framework is an opinionated approach to agile development, viewing story points as a crucial abstraction of work, complexity, and risk, grounded in a realistic assessment of available developer time.

Foundation: Realistic Available Developer Time

A standard two-week sprint provides 80 working hours per developer. However, several fixed time commitments must be deducted to calculate realistic availability:

  • Organization Overheads
    Approximately 2 hours per sprint for general meetings and mandatory trainings (e.g., HR sessions or company-wide meetings).
  • Sprint Ceremonies
    About 18 hours per two-week sprint, allocated as follows:
    • Sprint Planning
      Up to 4 hours (2 hours per week of sprint length)
    • Daily Scrum
      15 minutes daily, totaling 2.5 hours per two-week sprint (10 working days)
    • Sprint Review
      Up to 2 hours (1 hour per week)
    • Sprint Retrospective
      Up to 1.5 hours (45 minutes per week)
    • Product Backlog Refinement (Grooming)
      Up to 10% of total capacity (~8 hours per developer)

After these deductions, developers are left with roughly 60 effective working hours per sprint. To maintain product health, it's recommended to reserve 20% of this time (~12 hours) for handling bugs and technical debt. This results in about 48 hours per sprint available for new feature development per developer.

Definitions

  • Base Hours
    The developer's best estimate of the focused, hands-on time needed to complete the story. This includes tasks such as coding, debugging, minor design discussions, environment setup, documentation, and other related activities—assuming ideal conditions (no interruptions, clear requirements, and the necessary skills already in place).

  • Complexity
    The inherent difficulty of the task, considering factors like logic depth, number of components involved, unfamiliar technologies, and the overall learning curve.

  • Risk
    The level of uncertainty surrounding the work, including unclear requirements, unstable dependencies (e.g., APIs or services), potential technical surprises, and reliance on other teams or systems.

Core Estimation Formula for Individual Stories

Calculated Time (CT) for each story is derived using the following transparent formula:

Calculated Time (CT) = Base Hours (H) * Complexity Modifier (C) * Risk Modifier (R)

  • Base Hours (H)
    This is the estimate of raw, uninterrupted active working time required to complete the task. Typical inputs might range from 0.5 hours for trivial tasks up to larger, but still manageable, chunks like 30 hours (for example, 0.5h, 1h, 2h, 4h, 8h, 12h, 16h, 20h, 24h, 30h).

  • Complexity Modifier (C)
    This factor accounts for the inherent intricacy of the task:

    Level Modifier Description
    None 1.0 Straightforward, well-understood, routine
    Low 1.25 Minor intricacies, few moving parts, familiar patterns
    Medium 1.6 Moderately complex, requires careful design, several components, some new logic
    High 2.2 Very complex, significant architectural challenges, many interdependencies, novel solutions
    Extreme 3.0 Groundbreaking, pushing technological boundaries, highly intricate system-wide impacts

  • Risk Modifier (R)
    This factor addresses uncertainties and potential impediments:

    Level Modifier Description
    None 1.0 Clear requirements, no external dependencies, proven technology, stable environment
    Low 1.2 Minor uncertainties, well-defined internal dependencies, stable and familiar technology
    Medium 1.5 Some unclear requirements, potential for minor blockers, new but understood technology, some external team dependencies
    High 1.9 Significant unknowns, high chance of impediments, reliance on unstable or new external factors, critical path dependencies
    Extreme 2.5 Major unknowns, almost certain significant blockers, brand new or unproven technology, critical and unreliable dependencies

Mapping Calculated Time to Story Points

Any task with a Calculated Time (CT) greater than 60 hours must be broken down into smaller, independently deliverable stories. For tasks within the 60-hour threshold, the Calculated Time is converted directly into story points using the following formula:

Story Points = (CT / 60) * 13

The result is then rounded up to the next Fibonacci number (1, 2, 3, 5, 8, 13), unless it exactly matches a Fibonacci value.

Execution Principles

[!TIP] Agile isn't cowboy coding. It is not a license for improvisation. It’s a disciplined framework, not a free-for-all approach to "figuring things out later."

  • Single Developer Ownership
    Every story must be independently deliverable by a single developer, no shared ownership or parallel effort.
  • Planning Point Allocation
    Assign story points not only to user stories but also to bugs and spikes to reflect their planning and capacity impact.
  • Velocity Measurement
    Track two types of velocity, product velocity for User Stories, and engineering velocity for all work items, including Bugs and Spikes.
  • Scrum Discipline
    The Scrum Master protects the team and ensures strict adherence to Scrum roles, ceremonies, and artifacts—no compromises.
  • Backlog Authority
    The Product Owner has the final say on the backlog’s content and priority. Their decisions guide what gets built and when.
  • Definition of Done (DoD) Reinforcement
    Delivery isn't complete until the code is clean, tested, maintainable, and meets all quality and acceptance criteria.
  • Technical Debt Visibility
    The Development Team drives the issue by making the impact of technical debt undeniable and quantifiable, continuously educating the Product Owner, and integrating quality into the "Definition of Done".