Blog
Mert Özen's blog posts on software development, backend, frontend, and DevOps.
Jira Automation and GitHub Integration: Rules, Smart Values, Usage Limits and the REST API
Jira automation rules are made of triggers, conditions, actions and branches; from 3 December 2026 every step that runs is billed by usage, and by default a rule's action does not trigger another rule. The post covers Bookstore's four rules, the step count, GitHub for Atlassian and smart commits, and a .NET tool that checks commit messages and drafts release notes with REST API v3.
JQL, Filters and Dashboards: Asking the Right Question Without Misusing Metrics
JQL works with clauses made of a field, an operator and a value or function; currentUser(), openSprints(), startOfWeek() and membersOf() each support only certain operators. The post covers the Bookstore team's queries, keeping filters in the repo and checking them with a .NET tool, sharing filters and dashboards, which question each Jira report answers and the trap of turning a dashboard into a personal performance board.
Board and Workflow Design in Jira: Statuses, Transitions, Columns and WIP Limits
Jira's reports read whether an item is finished from two places: the board's right-most column and the resolution field; if they are not set up consistently, the board and the filters contradict each other. The post derives the Bookstore workflow from the Definition of Workflow and covers transition names, the resolution rule, column mapping, the Scrum board, column constraints, swimlanes and custom filters.
Jira Cloud's Model: Spaces, Work Items, Work Types, Hierarchy and Team-Managed vs Company-Managed
In Jira Cloud a project is now a space and an issue is now a work item; the API and JQL still accept the old names. The post builds the work type hierarchy and the Parent relationship with Bookstore's Institutional Ordering epic, explains team-managed versus company-managed spaces, why there is no conversion between them, what a move loses and when Jira is too heavy.
BDD in .NET: Binding Gherkin Scenarios to the Bookstore API with Reqnroll 3
SpecFlow reached end of life on December 31, 2024; the current way to run Gherkin scenarios in .NET is Reqnroll 3, with the Reqnroll.xunit.v3 package for xUnit v3. We bind Bookstore's institutional order scenarios to the API on .NET 10: project setup, step definitions, context injection, WebApplicationFactory, a diagnostic hook for failures, living documentation with the HTML formatter and filtering by tag, plus a pitfall observed under Turkish culture.
Executable Specifications with Gherkin: Given-When-Then, Rule, Scenario Outline and Writing Declarative Scenarios
Gherkin turns the rules and examples found in Example Mapping into a specification that stakeholders can read and a test runner can execute; a good scenario describes the business rule, not the UI. Using Bookstore's institutional order rules, we cover Feature, Rule, Background, Scenario Outline, Examples and data tables, declarative versus imperative scenarios, the Turkish keyword decision and Gherkin anti-patterns.
Non-Functional Requirements: The ISO/IEC 25010:2023 Quality Model, Making Them Measurable and Where to Record Them
A non-functional requirement states what quality a behaviour must have, and it only works when written with its environment, measure and owner. We cover the nine characteristics of ISO/IEC 25010:2023 and what changed since 2011, turning "make it fast" into a scenario built from data and measurement, accessibility (WCAG 2.2), KVKK, audit and security requirements for institutional orders, and where to record them: acceptance criteria, the Definition of Done, ADRs or fitness functions.
Acceptance Criteria and Example Mapping: Clarifying Rules with Examples
Acceptance criteria are a story's conditions of acceptance, and they work best when every rule has concrete examples under it. Using Bookstore's institutional discount and partial shipment cards, we cover rule-based and scenario-based criteria, how they differ from the Definition of Done and Definition of Ready, a four-colour Example Mapping session, and deciding at the end whether a story is ready, should be split or needs investigation.
Story Mapping and Splitting Stories: Walking Skeleton, Vertical Slices and Choosing the First Release
A story map arranges stories left to right by the user's flow and top to bottom by priority, exposing the gaps a flat backlog hides and anchoring the first release on an end-to-end walking skeleton. We draw Bookstore's institutional order map, choose the skeleton and release slices, split large stories by rules, data, exceptions, workflow steps, manual-first and spikes, and explain why splitting by layer is a bad idea.
From Use Cases to User Stories: The 3Cs, INVEST and When Use Cases Are Still Better
A use case is the map showing the whole and its branches, while a user story is a unit of delivery from that map that gives value on its own; not every alternative flow has to become a story. We split Bookstore's institutional order use case into seven stories and acceptance conditions, covering Jeffries' card-conversation-confirmation trio, the limits of the "As a / I want / so that" template, the INVEST check, epics versus stories versus tasks, and when use cases are still better.
Requirements Elicitation: Uncovering the Real Need with Interviews, Observation, Workshops and Prototypes
Elicitation is not gathering requirements that already exist; it is uncovering unspoken needs with interviews, observation, document analysis, workshops and prototypes, then confirming them with stakeholders. For Bookstore's bulk orders from schools and libraries we build a stakeholder map, run a "tell me about the last time" interview, observe customer service, surface conflicts in a workshop, test a one-day Angular prototype, and produce a glossary and an open questions list.
What Is a Requirement and Why Is It Misunderstood? Types, Qualities of a Good Requirement and Separating Problem from Solution
A requirement is not a screen but a statement of a need together with its constraints and conditions. Using Bookstore's bulk ordering feature for schools and libraries, we cover business, stakeholder, functional, non-functional, constraint and transition levels, the qualities of a good requirement in ISO/IEC/IEEE 29148, hunting vague words, and finding the problem behind a solution sentence like "an Excel upload screen".