DEV Community: Denis Glushko

Why Enterprise Agile Needs Less Scrum and More Economic Thinking

Denis Glushko — Wed, 24 Jun 2026 11:48:17 +0000

Most Agile transformations focus on process.
But enterprise success depends on decisions.
And decisions are economic.

The Hidden Problem
Teams follow Agile perfectly:

sprint planning
stand-ups
demos

But still:

wrong features are delivered
valuable work is delayed
priorities constantly change

Why?
Because:

Process does not equal value

Agile Without Economics Is Incomplete
Agile tells you how to deliver.
It doesn’t fully define:

what to prioritize
how to compare initiatives
how to allocate capacity

That’s where economic thinking comes in.

The Missing Layer: Portfolio Economics
Every organization has limited capacity.
Every decision is a trade-off.
But most enterprises don’t treat it that way.
Instead:

everything is “important”
no one owns prioritization
decisions depend on influence

What Economic Thinking Looks Like
Instead of asking:

“Can we do this?”

Ask:

“Is this worth doing compared to alternatives?”

Practical Model
Evaluate initiatives across:

business value
urgency
risk reduction
effort

Then compare them consistently.

Why This Changes Everything
It creates:

transparency
alignment
accountability

And removes:

politics
guesswork
noise

Agile + Economics = Real Enterprise Agility
Without economics:

Agile becomes delivery engine

With economics:

Agile becomes value engine

Final Thought
Scrum won’t fix your portfolio.
Ceremonies won’t fix prioritization.
Velocity won’t fix strategy.
But economic thinking will.
Because:

In enterprise Agile,
the biggest bottleneck is not delivery

It’s decision-making

AI in Project Management: Why Faster Delivery Can Make Things Worse

Denis Glushko — Wed, 24 Jun 2026 11:46:56 +0000

AI is everywhere.
It writes tickets, summarizes meetings, generates reports, predicts risks, and even suggests priorities.
And most teams are asking:

“How can AI make us faster?”

But that’s the wrong question.

The Real Risk of AI in Agile
AI doesn’t fix problems.
It amplifies them.
If your system is good → AI makes it better
If your system is broken → AI breaks it faster

Where AI Helps
Let’s be clear — AI is incredibly useful:

summarizing backlog items
generating acceptance criteria
analyzing risks
improving reporting
automating repetitive tasks

These are massive productivity gains.

Where AI Fails
But here’s what AI cannot do:

understand real business context
resolve stakeholder conflicts
define product strategy
make trade-offs across initiatives

And most importantly:

AI cannot decide what actually matters

The Dangerous Pattern
When organizations adopt AI blindly, this happens:

more tickets created
more backlog items generated
more documentation produced

Everything looks:
✅ structured
✅ efficient
✅ professional
But underneath?
❌ priorities are still unclear
❌ value is still undefined
❌ decisions are still weak

Faster ≠ Better
AI reduces effort, not complexity.
If you build the wrong thing faster:

rework increases
costs increase
frustration increases

AI doesn’t change that.

What High-Performing Teams Do Differently

Use AI for Execution — Not Strategy AI supports:

writing
analyzing
structuring

Humans own:

decisions
priorities
trade-offs

Focus on Decision Quality Before asking:

“Can AI generate this?”

Ask:

“Should this exist?”

Strengthen Product Ownership AI will expose weak Product Owners. Because:

writing stories → can be automated
defining value → cannot

The New Role of the Product Owner
From:

backlog manager

To:

decision-maker
value owner
alignment driver

Final Thought
AI will not replace project managers or Product Owners.
But it will expose who is:

thinking
vs
just managing tasks

Because:

AI makes execution faster
But only humans can make it meaningful

Agile Is Not Broken — Your Portfolio Is

Denis Glushko — Wed, 24 Jun 2026 11:44:57 +0000

Let’s be honest.
Agile isn’t failing in your organization.
Your portfolio management is.
Most Agile transformations focus on teams:

Scrum ceremonies
backlog grooming
sprint velocity
Jira dashboards

And teams do improve.
But the business outcome?
Still disappointing.

The Real Problem: Agile Solves Delivery, Not Decisions
Agile is great at answering:

“How do we deliver this faster?”

But enterprise environments struggle with a more important question:

“Why are we building this at all?”

That’s where things break.

What Actually Happens in Enterprises
At scale, Agile teams operate inside a system where:

priorities constantly shift
multiple stakeholders compete for attention
urgent requests override strategic work
governance sits outside delivery

This leads to a familiar pattern:

teams are busy
backlogs are full
releases happen

…but business impact is unclear.

The Portfolio Bottleneck
The issue isn’t execution.
It’s decision-making before execution.
Typical portfolio problems:

everything is “high priority”
no consistent prioritization model
value is assumed, not defined
trade-offs are avoided

So what happens?
Teams get overloaded with work that shouldn’t exist.

The Shift: From Delivery-Centric to Decision-Centric Agile
High-performing organizations don’t just optimize delivery.
They optimize what enters delivery.
This requires a mindset shift:
From:

“Let’s deliver everything faster”

To:

“Let’s deliver only what matters”

What Works Instead

Make Value Explicit Every initiative should answer:

What problem are we solving?
What measurable outcome do we expect?
What happens if we don’t do this?

No clear answer = no priority.

Introduce Structured Prioritization Stop relying on opinion. Start using criteria like:

business value
strategic alignment
urgency
complexity

This changes conversations from:

“We need this urgently”

To:

“This delivers more value than alternatives”

Limit Demand, Not Teams Most organizations try to increase team capacity. Better organizations:

reduce low-value work
protect team focus
say “no” more often

Align Governance With Flow Governance isn’t the enemy. But if it lives outside Agile, it creates bottlenecks. Bring it inside:

define rules upfront
integrate approval into flow
automate where possible

The Hard Truth
Agile teams rarely fail.
The system around them does.
If your portfolio is broken:

Agile will look ineffective
teams will feel frustrated
stakeholders will lose trust

Final Thought
Agile doesn’t need to be fixed.
Your decision system does.
Because in the end:

Delivering fast doesn’t matter
If you’re delivering the wrong things

Debunking Common Misconceptions About Remote Work

Denis Glushko — Fri, 19 Jun 2026 11:59:20 +0000

According to Forbes Advisor, by 2025, an estimated 32.6 million Americans will be working remotely, which equates to about 22% of the workforce
USA TODAY reports that 36% of U.S. white-collar workers who have reached, at most, a high school degree or equivalent are fully remote
In the European Union, 22% of employed people aged 15 to 64 worked from home in 2023, according to new data by Eurostat. This consisted of 9% who usually worked from home and 13% who worked from home only occasionally
The Netherlands had the highest share of people who worked from home at least occasionally in 2023 at 51.9%, followed by Sweden (45.3%), Iceland (42.6%), Norway, and Finland (around 42%)

Remote work has become a significant part of the modern work landscape, yet several misconceptions persist. Let’s explore and debunk some of the most common myths surrounding remote work.

Myth 1: Remote Workers Are Less Productive

A widespread belief is that remote workers are less productive due to the lack of direct supervision. However, this is far from the truth. Numerous studies have demonstrated that remote workers often outperform their in-office counterparts. The absence of typical office distractions, such as in-personal meetings and casual conversations, allows remote workers to focus better on their tasks. Additionally, remote workers often have more control over their work environment, which can lead to increased productivity and job satisfaction.

Myth 2: Remote Work Leads to Isolation

While it’s true that remote work can sometimes result in feelings of isolation, many remote workers actively seek social interactions through virtual meetings, coworking spaces, and social media. Companies can also play a significant role in mitigating isolation by organizing regular virtual team-building activities and promoting open communication. By fostering a sense of community and ensuring that employees feel connected, organizations can help remote workers maintain a healthy social balance.

Myth 3: Communication Breaks Down in Remote Work

Another common misconception is that communication suffers when teams are not physically together. In reality, remote work can enhance communication through the use of digital tools like Slack, Zoom, and Microsoft Teams. These platforms facilitate real-time communication and collaboration, often making interactions more efficient than traditional methods. With clear communication channels and regular check-ins, remote teams can maintain strong communication and collaboration.

Myth 4: Remote Workers Are Always Available

There’s a belief that remote workers are constantly on call and can work at any time. This misconception can lead to burnout if not addressed properly. It’s crucial for remote workers to set clear boundaries and for employers to respect these boundaries to maintain a healthy work-life balance. Establishing set working hours and encouraging employees to disconnect after work can help prevent burnout and ensure that remote workers remain productive and satisfied.

Myth 5: Remote Work Is Only Suitable for Certain Jobs

While some jobs are inherently more suited to remote work, the range of roles that can be performed remotely is expanding. With the right tools and processes, many traditionally office-based jobs can now be done remotely. Advances in technology have made it possible for a wide variety of tasks to be completed from anywhere, allowing more employees to enjoy the benefits of remote work.

Myth 6: Remote Work Erodes Company Culture

There’s a fear that remote work will weaken company culture. However, with intentional efforts, companies can maintain and even strengthen their culture. Regular virtual meetings, recognition programs, and opportunities for social interaction can help keep employees engaged and connected. By prioritizing company culture and making a concerted effort to include remote workers in all aspects of the organization, companies can ensure that their culture remains strong.

The Future of Remote Work

As remote work continues to evolve, it’s clear that it is here to stay. Hybrid work models, which combine remote and in-office work, are becoming increasingly popular. These models offer the best of both worlds, providing flexibility while maintaining opportunities for in-person interaction. Organizations that embrace remote work and virtual collaboration are likely to see numerous benefits, including increased employee satisfaction, higher productivity, and access to a global talent pool.

However, success in this new environment requires a proactive approach to addressing the challenges and leveraging the opportunities that remote work presents. By debunking these common misconceptions and adopting best practices, organizations can better support their remote workers and create a thriving, productive work environment.

In conclusion, remote work has transformed the way we work. By understanding and addressing the misconceptions surrounding remote work, organizations can better navigate this new normal and leverage the benefits of remote work to enhance productivity and employee satisfaction. With the right strategies and tools in place, remote work can be a highly effective and rewarding way to work.

Challenges in Implementing AI in Agile Projects

Denis Glushko — Fri, 19 Jun 2026 11:54:29 +0000

Integrating Artificial Intelligence (AI) into agile projects offers numerous benefits, but it also presents several challenges that organizations must navigate. Understanding these challenges is crucial for successful implementation and maximizing the potential of AI in agile environments.

Resistance to Change

One of the most significant hurdles in implementing AI in agile projects is resistance to change. Team members who are unfamiliar with AI or fear that it might replace their jobs can be hesitant to adopt new tools and practices. This resistance can slow down the integration process and reduce the effectiveness of AI solutions. To overcome this, organizations need to focus on education and transparency. Demonstrating the value that AI can bring to the team and ensuring that employees understand how AI will enhance their roles rather than replace them is essential.

Data Quality and Availability

AI algorithms rely heavily on data to make accurate predictions and provide valuable insights. However, poor quality data or insufficient data can significantly impact the effectiveness of AI. Ensuring that data is clean, relevant, and accessible is crucial for successful AI implementation. Organizations must invest in data management practices, including data cleaning, validation, and integration, to ensure that their AI systems have the high-quality data they need to function effectively.

Integration with Existing Systems

Integrating AI tools with existing project management systems and workflows can be complex. Compatibility issues, data migration challenges, and the need for customization can pose significant hurdles. This complexity requires careful planning and collaboration with IT teams to address these challenges effectively. Organizations should conduct thorough assessments of their current systems and workflows to identify potential integration issues and develop strategies to mitigate them.

Skill Shortage

There is a notable shortage of professionals with the skills required to implement and manage AI technologies. This skills gap can slow down the adoption of AI in agile projects. To address this issue, organizations need to invest in training and development for their existing team members or hire skilled professionals with expertise in AI and agile methodologies. Building a team with the right skills is essential for leveraging the full potential of AI in agile projects.

Maintaining Code Quality

AI-generated code, especially from generative AI models, needs to be carefully vetted to ensure it meets quality standards. There is a risk of introducing errors or vulnerabilities if the generated code is not thoroughly reviewed and tested. Organizations must establish robust code review processes and quality assurance practices to ensure that AI-generated code is reliable and secure.

Ethical and Security Concerns

The use of AI raises ethical and security concerns, particularly regarding data privacy and the potential for biased decision-making. Implementing robust security measures and ethical guidelines is essential to address these concerns and ensure responsible AI use. Organizations should develop and enforce policies that prioritize data privacy, security, and ethical considerations in their AI projects.

Cost and Resource Allocation

Implementing AI can be resource-intensive, requiring significant investment in technology, infrastructure, and training. Organizations need to carefully consider the cost-benefit ratio and allocate resources effectively to ensure a successful implementation. This includes budgeting for AI tools, infrastructure upgrades, and ongoing training and support for team members.

Strategies for Overcoming Challenges

To successfully integrate AI into agile projects, you can adopt several strategies:

Education and Training: Invest in training programs to educate team members about AI technologies and their benefits. This can help reduce resistance to change and build a culture of continuous learning.
Data Management: Implement robust data management practices to ensure that AI systems have access to high-quality data. This includes data cleaning, validation, and integration processes.
Collaboration with IT Teams: Work closely with IT teams to address integration challenges and ensure that AI tools are compatible with existing systems and workflows.
Hiring and Development: Hire skilled professionals with expertise in AI and agile methodologies, and invest in the development of existing team members to build a strong, capable team.
Ethical Guidelines and Security Measures: Develop and enforce ethical guidelines and security measures to address concerns related to data privacy and biased decision-making.
Resource Allocation: Carefully allocate resources to ensure that AI implementation is cost-effective and sustainable. This includes budgeting for technology, infrastructure, and training.

By acknowledging and addressing these challenges, you can better navigate the complexities of integrating AI into agile projects and fully leverage the benefits that AI has to offer. With the right strategies and tools in place, AI can significantly enhance productivity, decision-making, and overall project success in agile environments.

The Integration of AI in Agile Project Management and Decision-Making

Denis Glushko — Fri, 19 Jun 2026 11:51:52 +0000

In recent years, the integration of Artificial Intelligence (AI) into agile project management and decision-making has revolutionized the way teams operate. AI algorithms are now capable of predicting project trajectories, identifying potential bottlenecks, and providing valuable insights for smarter decision-making. This technological advancement is enhancing productivity and freeing up time for teams to focus on more strategic tasks.

Predicting Project Trajectories

One of the most significant contributions of AI in agile project management is its ability to predict project trajectories. By analyzing historical data and current project parameters, AI algorithms can forecast future outcomes with remarkable accuracy. This predictive capability allows project managers to anticipate potential issues and make proactive adjustments to keep projects on track. For instance, AI can predict delays in project timelines based on past performance data, enabling teams to take corrective actions before problems escalate.

Identifying Potential Bottlenecks

AI is also instrumental in identifying potential bottlenecks in project workflows. By continuously monitoring project progress and analyzing data from various sources, AI can pinpoint areas where work is slowing down or where resources are being underutilized. This real-time analysis helps teams address issues promptly, ensuring that projects run smoothly and efficiently. For example, AI can detect when a particular task is taking longer than expected and suggest reallocating resources to prevent delays.

Providing Insights for Smarter Decision-Making

The insights provided by AI are invaluable for making smarter decisions in agile project management. AI algorithms can analyze vast amounts of data to uncover patterns and trends that may not be immediately apparent to human observers. These insights can inform decision-making at all levels, from strategic planning to day-to-day operations. For instance, AI can analyze customer feedback and market trends to help teams prioritize features that will deliver the most value to users.

Enhancing Productivity with Automation Tools

Automation tools powered by AI are being integrated with agile practices to enhance productivity and free up time for teams. These tools can automate repetitive tasks, such as updating project status, generating reports, and managing workflows. By reducing the manual workload, automation allows team members to focus on more strategic and creative aspects of their work. For example, AI-powered chatbots can handle routine inquiries and support tasks, freeing up human resources for more complex problem-solving.

The Future of AI in Agile Project Management

The future of AI in agile project management looks promising, with continuous advancements in technology and increasing adoption by organizations. As AI algorithms become more sophisticated, their ability to predict, analyze, and optimize project workflows will only improve. This will lead to even greater efficiencies and more successful project outcomes.

Moreover, the integration of AI with other emerging technologies, such as the Internet of Things (IoT) and blockchain, will further enhance its capabilities. For instance, IoT devices can provide real-time data on project environments, while blockchain can ensure the security and transparency of project transactions. Together, these technologies will create a more connected and intelligent project management ecosystem.

In conclusion, AI is transforming agile project management and decision-making by predicting project trajectories, identifying potential bottlenecks, and providing insights for smarter decision-making. The integration of automation tools with agile practices is enhancing productivity and freeing up time for teams to focus on strategic tasks. As AI technology continues to evolve, its impact on agile project management will only grow, leading to more efficient and successful projects.

Agile User story splitting techniques.

Denis Glushko — Fri, 19 Jun 2026 11:48:33 +0000

Why do we need split user stories?
Easier to understand
Smaller stories provide faster feedback
Small stories increase progress

Split conditions:
What this is - if a story has multiple items listed in "what" make each a separate story.

When to use it - words such as "and" or "or" appear.

Helpful questions - Are all of these conditions helpful?

Example: As a customer I want to create an order and pay for the order using ApplePay:

As a customer I want to create an order
As a customer I want to pay for the order using ApplePay

Workflow
What this is - identify the specific steps in a workflow. Implement the workflow in stages, creating multiple stories for the incremental implementation.

When to use it - the initial story describes a workflow or a process

Helpful questions - What steps does a user perform? Are all these steps necessary? Can steps be simplified?

Example: As a customer I want to create an order

As a customer I can view the items on the menu
As a customer I can select the want in my order
As a customer I can review my order
As a customer I can submit my order

Use case scenarios.
What is this - similar to the workflow pattern, one story represents the happy path, different stories for the alternative paths.

When to use it - the initial story refers to an interaction described by a use case

Helpful question - What does the happy/alternative flow look like? Are all the alternative flows necessary? Can the alternative flows be simplified?

Example: As a customer I want to create an order want to create an order

As a customer I want to order 1 item
As a customer I want to order multiple items
As a customer I want to cancel my order

Operations
What is this - splitting a story based on the different operations done on an entity (Create, read, update, delete).

When to Use it - The story is about managing or configuring something.

Helpful questions - What operations does the story entail? All of these operations necessary?

Example: As a restaurant owner I want to manage my restaurant profile so that people can order from my restaurant:

As a restaurant owner I can create a restaurant profile
As a restaurant owner I can update a restaurant profile
As a restaurant owner I can view a restaurant profile
As a restaurant owner Ican delete a restaurant profile

Zero->One->Many
What this is - splitting a story that deals with multiple instances of the entity into stories that deal with one instance, and then multiple instances.

When to Use it - You are working with an entity where multiple instances are allowed

Helpful questions - Do we need to be able to handle multiple instances, or 1 instance is sufficient.

Example - As a restaurant owner, I want to view customer order.

As a restaurant owner, I want to view customer order with no menu items.
As a restaurant owner, I want to view customer order with 1 menu item.
As a restaurant owner, I want to view customer order with multiple menu items.

Core functionality Vs Enhancements.
What this is - Splitting a story to deal with the simple core conditions and then enhancing the functionality with additional user stories.

When to Use it - When the story has a simple core that provides most of the learning.

Questions: What's the simplest version of this? What data types are supported? What parameters are relevant?

Example: As a customer I want to see my past orders so that i can see what I have eaten before

As a customer I can all of my orders
As a customer I can see orders for a given location.
As a customer I can see all the orders in the past 3 month
As a customer I can orders in revers date order

Major effort
What this is? Splitting a story in the way that requires substantial effort for the first story and less effort for all subsequent stories.

When to use it? When you apply the most obvious split, any story you do first is the most difficult.

Questions: Can we create the necessary infrastructure and deliver value at the same time?

Example: As a customer I can pay for my orders with VISA, MasterCard, UnionPay so that I don't have to deal with cash

As a customer I can pay with one debit card type (VISA, MasterCard, UnionPay)
As a customer I can pay with all debit card types, given one card type already done.

Acceptance criteria
What this is? Split a user story into multiple stories to handle different scenarios in the Acceptance criteria.

When to use it? When the team identifies the multiple scenarios for the story, or accurate, but not entirely relevant acceptance criteria identified.

Questions: What tests are used to verify this story? What acceptance criteria apply? What scenarios are relevant? Are all test scenarios are necessary?

Example: As a customer I want to create an order so that i can have something to eat.

As a customer I want to create an order with an approved debit card.
As a customer I want to create an order with a declined debit card.
As a customer I want to create an order with an in-stock item.
As a customer I want to create an order with an item not in stock.

Variations in data
What this is? The story does the same thing to different types of data. Create a story for each option.

When to use it? When a solution has to support multiple options.

Questions: Are these options necessary right now? What is the most common option we need to care for right away.

Example: As a customer I want to view the menu in my native language, so i can decide what I Want to eat.

As a customer I want to view the menu in English
As a customer I want to view the menu in Kazakh
As a customer I want to view the menu in Russian

Data Boundaries
What this is - Splitting a story dealing with several attributes of the same entity. Support a few key elements first and introduce remaining data elements later via additional stories.

When to use it - When s story dealing with several different pieces of data.

Questions - What are the essential data elements we need to have? What data elements are not needed right now.

Example: As a customer I want to view menu item information so I can decide what I want to eat

As a customer I want to view dish name & description
As a customer I want to view dish ingredients
As a customer I want to view nutritional information
As a customer I want to view picture of dish

Interface variations
What this is - Splitting a story dealing with a complex interface with addition stories to incrementally add in complexity

When to use it - When the user story deals with a complex user interface where a simpler one will work in the meantime

Questions - What is the simplest user interface we can use?

Example: As a customer I can view the menu so I can select what I want to eat.

As a customer I can view the menu as .PDF
As a customer I can view the menu as a searchable web-page
As a customer I can view the native in a browser

Platform options
What this is? Split a story adding a new user interface by the various platforms thar are applicable

when to use it? When adding a new user interface that may be accessed by multiple different platforms

Questions - which platforms are supported? Are all platforms required? Are some platforms more difficult to support than others.

Example: As a customer I want to create an order so that i can get something to eat

As a customer I want to create an order on my android device
As a customer I want to an order on my iPad
As a customer I want to an order on my iPhone

Business rules
What this is? Split a user story so that complex business rules are handled by separate business rules. A special case of this is deferring input validation to a later story.

When to use it? When a story has a variety of business rules, often identified by a large number of examples.

Questions - What rules apply to this story. Are all of this rules necessary. Can simpler rules suffice.

Example: As a customer I can use a credit card to pay for my order.

As a customer I want to know when I didn't provide a properly formatted CC number.
As a customer I want to know when I didn't provide a proper expiration date.
As a customer I want to know when I didn't provide a proper expiration date.

Role
What this is? Split a story so that the functionality is implemented at different times for different roles.

When to use it - When a story impacts multiple roles, and the impact is different for each role.

Questions - What roles are involved in this story. Are any roles necessary now.

Example: As a customer I want to create an order, so that I can get something to eat.

As a customer I want to create an order
As a restaurant owner, I want to create an order for a customer.

Defer system qualities
What this is? Split the story to deliver the necessary functionality, then include extra stories to improve performance, scalability, usability or precision.

When to use it? When the base functionality does not exist, implementation is not that hard, the team can learn a lot from it, and the hard work is in making it better.

Questions. Is it necessary to have the optimal performance now?

Example: As a customer I want to know that the restaurant received my order so that I'm sure I'll get some food.

As a customer I want to know that the restaurant received my order.
As a customer I want to know that the restaurant received my order within 5 seconds.

Spikes
What this is? Split the story for some research and investigation on functionality before implementing.

When to use it? When the team finds they are uncertain about the implementation of a story and they need to do some research.

Questions. What are the 1-3 questions you have about the story.

Example: As a customer I want to see the menu in the language of my choice so that I can pick something I want

Spike: Investigate translation functionality
Spike: Research on performance optimization

Low Fidelity/High Fidelity
What this is? Split the story into gradual increase of quality.

When to use it? When getting to the optimal level of quality or usability is too expensive to deliver a solution immediately.

Questions. What is good enough for this functionality

Example: As a customer I would like a recommendation of what food to order so that I can know I'm getting a good dish.

As a customer I want to see a numeric rank of top selling menu items.
As a customer I want to see the aggregate ranking of customers.

Transient then persistent
What this is? Split the stories based on actions to pass data along and those necessary to save data.

When to use it? When the story deals with functionality that includes storing data but does not require storing data.

Questions. Do we have to store this data

Example: As a customer I want to use a credit card to pay for my order so that I don't have to carry cash.

Collect credit card info and use to gain authorization but not store it.
As a customer, I want to save my credit card information to my profile.

Dummy then Dynamic data
What this is? Split stories to first use static data and then add stories to make the data dynamic.

When to use it? When the story covers parameters where the values differ depending on conditions.

Questions. Does the data need to be dynamic.

Example: As a customer I want to search for menu items.

As a customer I want to search for menu items
As a customer I want to search for menu items less than $5 or over $5.
As a customer I want to search for menu items by food type.

Manual then automated
What this is? Split stories that utilize an existing manual process. Implement the functionality that does not exist.

When to use it? When functionality you are developing interacts with an existing manual process, develop the functionality but tin the short term, do not automate the manual.

Questions. Is it necessary to automate the manual process right now.

Example: As a customer I want to use multiple credit cards to pay for my order.

As a customer I want to use a credit card to pay for my order.

Defer Error Handling or logging
What this is. Split a story so that you focus on functionality first, then go back and provide functionality to log errors and handle them

When to use it. When you need to gain feedback on functionality quickly to determine whether to keep it.

Questions. Is it necessary to deal with exception for this functionality.

Example: As a restaurant owner I want to authorize the customer's credit card payment

As a restaurant owner I want to know when the authorization process encountered errors.
As a restaurant owner I want to know what errors the authorization process encountered.

Effective techniques for breaking down stories in Agile delivery teams.

Denis Glushko — Fri, 19 Jun 2026 11:29:02 +0000

User story splitting is the process of breaking down a large user story into smaller, more manageable pieces that can be developed and tested incrementally.

In the realm of Agile software development, User Stories serve as a method to articulate the system’s functional requirements from the viewpoint of the end user. They are employed to identify and rank the features that are essential for the system to provide value to its users. However, the implementation of user stories often presents a challenge due to their large and complex nature. This is where the idea of user story splitting becomes relevant. Even when a user story is divided, the new stories should adhere to the following criteria:

The user stories should be of a size that allows for completion within a single iteration.
Every user story, when considered individually, should retain the characteristic of having quantifiable business value.

Article content

There are 2 main approaches:
Vertical slice splitting focuses on breaking down the user story into smaller parts that represent the different layers of the application. This approach aims to deliver a complete, end-to-end slice of the functionality, from the user interface all the way down to the data store.

Advantages are: Early feedback, clear understanding, reduced complexity, Deliver fast, motivation.

Horizontal slice splitting breaks down the user story into smaller parts representing different areas of the application. This approach is more focused on delivering a set of related functionalities, such as searching, browsing, and updating, rather than delivering a complete end-to-end slice of the application.

Disadvantages are: No E2E visibility, increased complexity, increased overhead, reduced focus & flexibility.

Article content

Some strategies for Vertical user story slicing
Workflow steps?

What steps does a user perform?

Are all steps necessary? (right now)

Can some steps be simplified? (at the moment)

Example: Payment order options - delivery? payment option?

Business rules

What business rules apply to this user story?

Are all business rules necessary?

Can simplified approach take place?

Example: Payment methods allowed during the purchase process

Happy/unhappy flows (a default scenario featuring no exceptional condition)

what does happy/unhappy flows look like?

Are all unhappy flows necessary?

Can unhappy flows be simplified?

Example: failures during payment order process and recovery

Input options?

Which platforms are supported?

are all platforms necessary?

Are platforms more complex than other?

Example: Web 3.0, Apple, Android?

Data parameters & types?

what data types supported?

What data parameters are necessary?

What parameters are relevant?

Example: Reports (tables graphs); only integer data is enough atm.

Operations

What operations does the story entail?

Are all operations necessary?

Can any operation be simplified?

Example: read/update/ etc..

Test cases, acceptance criteria?

what test covers the user story to verify?

What acceptance criteria apply?

Do we need all scenarios?

Example: some test scenarios could be very complex and covers different functional requirements.

Roles?

What roles involved?

All of them necessary?

Example: create? confirm?

To sum up, the decision to use Vertical Slice or Horizontal Slice user story splitting hinges on your project’s unique requirements and the development framework. Each method has its pros and cons, and the best fit will be determined by your stakeholders’ needs, the intricacy of the functionality, and your development process’s limitations. No matter which strategy you adopt, it’s crucial to consistently review and modify your user story-splitting approach to ensure it remains aligned with your objectives and continues to provide value to your users.

What is 1 Story point?

Denis Glushko — Fri, 19 Jun 2026 11:27:54 +0000

Story points are a way of estimating the effort required to complete a user story or any other piece of work in agile software development. A user story is a short description of a feature or functionality that the customer wants from the product.

Important to mention, as many development team members misunderstand. Story points are not related to time, but rather to the complexity, amount of work, and risk or uncertainty of the task.

One story point is a unit of measurement that represents the relative size of a user story. It is not an absolute value, but a way of comparing different user stories and prioritizing them. For example, a simple task might be assigned one story point, while a more complex task might be assigned five story points.

The benefit of using story points is that they allow the development team to estimate the work without getting bogged down by the details of implementation, such as how long it will take, what technologies will be used, or what dependencies will be involved. Story points also help the team to plan and track their progress, as well as to adjust their estimates based on their experience and feedback.

To estimate story points, the development team usually uses a technique called planning poker, where each team member votes on how many points they think a user story is worth, based on their experience and knowledge. The team then discusses the votes and reaches a consensus on the final estimate. Planning poker can help the team uncover hidden assumptions, dependencies, and risks, as well as to align their expectations and understanding of the work.

One story point is not a fixed amount of time or work, but a relative measure that can vary depending on the team, the project, and the context. Therefore, one story point for one team might not be the same as one story point for another team. The important thing is that the team uses a consistent and transparent method to estimate story points, and that they review and refine their estimates regularly.

I teach my team to keep in mind the following parts of 1 story point:

Volume – How much is there?
Complexity – How hard is it?
Knowledge – What’s known?
Uncertainty – What’s unknown?

Based on this knowledge development team members can be more precise in their estimations, moreover they can suggest the estimates to less experienced team members.

A general user story with one point is usually a simple and straightforward task that does not involve much complexity, work, or risk. Here is one possible example:

As a blog reader, I want to be able to leave a comment on a post so that I can share my feedback and opinions with the author and other readers.
This user story has one point because it is easy to understand, implement, and test. It does not require any advanced features or integrations, and it has a clear value for the user. The acceptance criteria for this user story could be something like:

The blog post has a comment section at the end of the page;
The reader can enter their name, email, and comment in the comment form;
The reader can submit their comment by clicking a button;
The comment is displayed below the comment form after submission;
The comment shows the reader’s name, email, and date and time of submission;
The reader can edit or delete their comment within a certain time limit;
The reader can see other comments from other readers on the same post;
The reader can reply to other comments and start a conversation;

SQL user story with one point could look like:

As a data analyst, I want to query the sales table by date and product category, so that I can generate a report on the monthly sales performance of each product category.
The acceptance criteria for this user story could be something like:

The sales table has columns for date, product_id, product_category, and sales_amount

The user can enter a date range and a product category as parameters for the query

The query returns the total sales amount for the selected product category within the date range

The query results are displayed in a tabular format

The query results can be exported to a CSV file

A front-end user story is a description of a feature or functionality that a user wants from the user interface of a web or mobile application. A front-end user story with one point example:

As a blog writer, I want to be able to format my posts with bold, italic, and underline options, so that I can emphasize certain words and phrases in my content.
The acceptance criteria for this user story could be something like:

The blog post editor has buttons for bold, italic, and underline options

The user can select some text and click on the buttons to apply the formatting

The user can see the formatted text in the preview mode

The user can save and publish the post with the formatting

The formatting is displayed correctly on the blog page

One way to write a user story for a back-end process is to use the following template: As a [type of user], I want [some goal] so that [some reason]. For example:

As a data analyst, I want to query the database with SQL so that I can generate reports for the management.
As a system administrator, I want to backup the data every night so that I can restore it in case of a disaster.
As a security officer, I want to encrypt the data in transit and at rest so that I can protect it from unauthorized access.
A user story for a back-end process should be small enough to be completed in one iteration, usually a few days or a week. A story point is a relative measure of the effort required to complete a user story, based on factors such as complexity, uncertainty, and risk. One way to estimate story points is to use a Fibonacci-like scale (1, 2, 3, 5, 8, 13, etc.) and compare the user stories with each other. For example:

Querying the database with SQL might be a 1-point story, as it is a simple and well-defined task.

Backing up the data every night might be a 3-point story, as it involves some configuration and testing.

Encrypting the data in transit and at rest might be a 5-point story, as it requires more technical knowledge and security standards.

Story points are a useful tool for agile development, as they help the team to focus on the value and scope of the work, rather than the time and cost. By using story points, the team can deliver better products that meet the customer's needs and expectations.