Skip to content

Process Methodology

Cengiz Ilerler edited this page Aug 9, 2026 · 5 revisions

DORA Core Model

The DORA (DevOps Research and Assessment) framework identifies the capabilities that drive software delivery performance and organizational outcomes.

DORA Core Model


DAMA-DMBOK

The DAMA-DMBOK (Data Management Body of Knowledge, 2nd ed., DAMA International) is the industry reference for data governance — covering data architecture, modeling, master/reference data, data quality, metadata management, integration, and warehousing.

DORA Core Model


Diátaxis

Diátaxis is the documentation framework that classifies technical writing into four distinct quadrants by audience need: Tutorial (learning-oriented), How-to (task-oriented), Reference (information-oriented), and Explanation (understanding-oriented). Each quadrant has its own shape, audience, and writing style — and conflating them produces docs that serve no one well.

Diátaxis Quadrants


Scrum Ceremonies & 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
      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 technical debt. This results in about 48 hours per sprint available for new feature development and bug fixing per developer.

Lifecycle

Teams

5W1H Work Item Mapping

5W1H Description Work Item Example
Why (The Goal) Strategic, product, and capability reason for the work InitiativeEpicFeature
What (The Value) The specific piece of value to be delivered or the work to be done Story / Bug / Spike / Enhancement
How (The Plan) How the team will technically implement the "What." Task
When (The Time) The timebox for delivery Iteration
Who (The Person) The person responsible for the work Assigned To
Where (The Area) The product area or component structure related to the work Area Path

Story Template

As a `[type of user]`,  
I want `[an action or goal]`  
so that `[a benefit or value]`

### Acceptance Criteria:
1. ...

Effort Estimation Factors

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

$$Fibonacci Numbers = 1, 1, 2, 3, 5, 8, 13, ...$$ $$Effort = MapToClosestFibonacci (Hours * Complexity * Risk)$$

P1 Definition

A P1 incident is the highest level of severity that indicates a system-wide failure, data loss, or critical risk requiring immediate, around-the-clock response and resolution. It affects a large portion of users or business operations and demands the highest priority for triage, escalation, and fix.

  • Security Breach or Major Vulnerabilit A confirmed or actively exploited security vulnerability that puts data, systems, or user privacy at high risk, requiring immediate containment and remediation.

  • Widespread Outage Multiple users are completely unable to access or use the system, and the issue is not caused by their local environment (e.g., same physical location, ISP, etc).

  • Active Data Corruption There is ongoing data corruption, and continuing without intervention will result in additional data loss or irreversible damage to business-critical data.

  • Critical Business Impact A core business function is completely down or severely impacted, preventing the company or its customers from conducting essential operations (e.g., transactions, orders, logins, or communications).

  • Regulatory or Compliance Violation A system issue that puts the organization at risk of violating legal, regulatory, or contractual obligations, particularly around data handling or availability.

  • Reputational Risk The incident is already or likely to become publicly visible (e.g., social media complaints, press coverage, customer escalation), potentially damaging the company’s brand.

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

  • 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.
  • Planning Point Allocation
    Assign story points not only to Stories but also to Bugs, Spikes and Enhancements to reflect their planning and capacity impact.
  • Sprint-Bound Work Story, Bug, Spike, Enhancement, and Task items must be completed within a single sprint.
  • Single Developer Ownership
    Every story must be independently deliverable by a single developer, no shared ownership or parallel effort.
  • 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".
  • Velocity Measurement
    Track two types of velocity, product velocity for Stories, and engineering velocity for all work items, including Bugs, Spikes and Enhacements.

Roles

Values

Agile Subway Map

Midnight Sailboat Retrospective Template

Clone this wiki locally