-
Notifications
You must be signed in to change notification settings - Fork 1
Process Methodology
The DORA (DevOps Research and Assessment) framework identifies the capabilities that drive software delivery performance and organizational outcomes.
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.
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.
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)
-
Sprint Planning
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.
| 5W1H | Description | Work Item Example |
|---|---|---|
| Why (The Goal) | Strategic, product, and capability reason for the work |
Initiative → Epic → Feature
|
| 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 |
As a `[type of user]`,
I want `[an action or goal]`
so that `[a benefit or value]`
### Acceptance Criteria:
1. ...-
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.
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.
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, andTaskitems 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.
This entire knowledge base is powered by caffeine, hard-won experience, and a passionate commitment to minimizing distractions.
If you borrow ideas or content, please cite your source. 😇








