Technologies and industries that were once dominated by one or two companies or were very much “human-focused” are coming under threat.

Google is losing ground to AI search, truck drivers may soon be a thing of the past, and low-skilled clerical jobs are being lost every day.

Will this disruption destroy the Software Engineering industry? I don’t think so, and I’ll tell you why.

Here’s what we’ll discuss:

1. The Phenomenon of "Vibe Coding"

2. How AI Has Changed Software Development

3. The Productivity Paradox

4. Why Human Engineers Are Still Critical

5. AI as a “Capability Multiplier”

6. Critical Skills for the AI Era

7. The Path Forward

The Phenomenon of "Vibe Coding"

If you follow tech discussions on X, you've likely seen the term "vibe coding" – the practice of building software through trial and error, intuition, and AI-generated code snippets without deep technical knowledge.

Modern AI assistants such as GitHub Copilot and ChatGPT can generate full functions, fix bugs, and create components based on simple descriptions. “Vibe Coders” are claiming that human coders will soon become obsolete.

From my perspective, these AI tools function more as skill multipliers than replacements.

They help talented developers work faster while exposing gaps in knowledge for less skilled programmers. Those lacking technical foundations will face problems they can't solve, but engineers who blend AI assistance with solid expertise will be able to be incredibly productive.

How AI Has Changed Software Development

The software industry has seen rapid adoption of AI coding tools based on Large Language Models that analyze code repositories to predict and suggest next steps.

These tools have transformed daily programming work by:

• Suggesting complete functions as you type

• Creating API endpoints from plain language descriptions

• Eliminating hours spent on standard code patterns

• Automating documentation tasks

• Handling repetitive logic quickly

This shift toward "vibe coding" speeds up feature delivery. Programmers can now build without mastering every technical detail – they describe what they want, get AI suggestions, and adjust until the code works.

The risk? Developers often push code they can't explain. They move quickly during building but struggle when systems break or need changing.

There's also a concerning trend of non-programmers selling AI-built applications. Recently, someone with zero coding background launched a paid service created entirely through AI prompts, only to face a data breach days later when hackers exploited basic security flaws. This is dangerous. It has wasted people's money and exposed their data. Imagine if this became common place due to the rise of “vibe coders”?

For anyone considering building software who isn’t a software engineer, there are a few basic levels of security that you need to consider:

• Adding authentication to your API endpoints: People can scan for open ports and endpoints across the internet. If they can then call your API endpoints without being authenticated, it can cause all sorts of problems

• Do not store passwords in plain text. This is a big no no. If you do this and your database gets exposed, those passwords are there for all to see. And if we’re being real, people re-use passwords, so those passwords will be their passwords for other sites too.

• SSL: Make sure your website is secure and has an up to date SSL certificate. Transmitting data in plain text is dangerous.

• Lock down unused ports: If you are hosting a backend service, make sure that any ports that you don’t use are locked down and people aren’t able to connect to them.

• If you have areas where people can upload files, limit the uploads to specific file types.

Those are just a few considerations around security for your site or product, but there are many more.

The Productivity Paradox

AI assistance dramatically increases code output – but volume doesn't equal value in software engineering.

These tools excel at syntax but have no understanding about system architecture, scalability concerns, and maintenance requirements. Just as typing speed doesn't create a better novel, code generation speed doesn't produce better software systems.

AI works for individual functions but struggles with architectural decisions, security planning, and long-term support needs. Without proper review and understanding, AI-generated code often becomes tomorrow's tech-debt and maintenance burden.

Consider this scenario: A developer implements an AI-created authentication system that works in isolation but causes subtle failures in users signing up to the product. Finding and fixing these integration issues might take experienced staff several days – negating any initial time savings. This is a quick path to losing money and trust.

Why Human Engineers Are Still Critical

While AI tools handle syntax well, they cannot:

1. Plan systems that grow with user demand

2. Create reliable deployment and testing pipelines

3. Anticipate unusual but critical failure cases

4. Make smart tradeoffs between performance and cost

5. Find non-obvious security weaknesses

Great engineers think beyond code. They develop patterns that help entire teams, select the right technologies, and plan both for success and failure scenarios.

Software creation involves complex tradeoffs: Do we prioritize speed or stability? Flexibility or simplicity? These decisions require both technical expertise and business knowledge.

The highest value engineers I work with spend more time thinking than typing. They consider: How will requirements evolve? What stress points might emerge? How will the system recover from failures?

As basic code generation becomes widely accessible, your value comes from understanding system interactions. The competitive edge will be with those who know why certain approaches succeed, where they might fail, and how to build resilient solutions.

Per the above, there are some things that AI without proper oversight can not do.

AI can, for instance, be great at passing simple prompts to create solutions to well known problems. If you use this prompt, for example:

Here’s the code you might get:

import json

def is_valid_json(input_string: str) -> bool:
    """
    Checks if the input string is valid JSON.

    Args:
        input_string (str): The JSON string to validate.

    Returns:
        bool: True if valid, False otherwise.
    """
    try:
        json.loads(input_string)
        return True
    except json.JSONDecodeError:
        return False

def main():
    user_input = input("Enter a JSON string to validate: ")
    if is_valid_json(user_input):
        print("✅ The input is valid JSON.")
    else:
        print("❌ The input is NOT valid JSON.")

if __name__ == "__main__":
    main()

Pretty basic.

I would not, though, ask an AI to build me a complex Forex Trading platform.

I’ll save you reading through all of the response, but suffice it to say that it was not able to do this for me.

I thought I’d break that down to a slightly smaller subset of a financial trading platform:

Now, I will admit, this got closer. Here was the result:

from fastapi import FastAPI, Request, HTTPException, Header
from pydantic import BaseModel, Field
from typing import Optional
import hmac
import hashlib
import logging

app = FastAPI()

# === CONFIGURATION ===
SHARED_SECRET = b"super_secure_shared_secret"  # Keep this secure

# === LOGGING SETUP ===
logging.basicConfig(level=logging.INFO)
logger = logging.getLogger("ems.fix")

# === Pydantic Model for Execution Report (simplified) ===
class ExecutionReport(BaseModel):
    msg_type: str = Field(default="J", const=True)
    cl_ord_id: str  # Tag 11
    order_id: str   # Tag 37
    exec_id: str    # Tag 17
    exec_type: str  # Tag 150
    ord_status: str # Tag 39
    symbol: str     # Tag 55 (e.g., EUR/USD)
    side: str       # Tag 54 (1=Buy, 2=Sell)
    leaves_qty: float  # Tag 151
    cum_qty: float     # Tag 14
    avg_px: float      # Tag 6
    transact_time: str # Tag 60 (ISO8601 string)

# === Helper: HMAC Validator ===
def verify_signature(payload: bytes, signature: str) -> bool:
    computed = hmac.new(SHARED_SECRET, payload, hashlib.sha256).hexdigest()
    return hmac.compare_digest(computed, signature)

# === Endpoint ===
@app.post("/fix/execution-report")
async def receive_execution_report(
    request: Request,
    x_signature: Optional[str] = Header(None)
):
    body = await request.body()

    if not x_signature or not verify_signature(body, x_signature):
        logger.warning("Invalid or missing signature.")
        raise HTTPException(status_code=403, detail="Unauthorized")

    try:
        report_data = ExecutionReport.parse_raw(body)
        logger.info(f"Execution Report received: {report_data.dict()}")
        # ✅ Here, you'd handle order updates, booking, etc.
        return {"status": "ok", "message": "Execution Report received"}
    except Exception as e:
        logger.exception("Invalid payload format.")
        raise HTTPException(status_code=400, detail=f"Invalid FIX message format: {str(e)}")

But this does not come close to the final version. Even if you could use this code as a part of your trading system, unless you know how to build and architect and entire software system, where do you go from here? You can tell your clients that they can send you an “ExecutionReport”, but then what?

I’ve read and heard the arguments that you “just need to be better at prompting to build bigger systems”. But where does the benefit come from then? The complexity of financial trading systems is beyond comprehension. Prompting a system well enough, with enough information to make it fully featured, scalable, secure, and extensible (not to mention able to be debugged) would itself be a mammoth task. So where is the time being saved? Is it even possible?

I’m yet to see any proof anywhere that anyone has build such a complex system without the oversight of a human, and I’m not convinced we will see it at any point in the near future.

AI as a “Capability Multiplier”

These AI tools help magnify existing capabilities rather than replacing them. Skilled developers become far more productive, while less skilled ones generate problems more quickly.

Effective engineers use AI to:

• Handle basic implementation tasks

• Create initial project frameworks

• Compare different solution approaches

• Move past challenging problems

Meanwhile, less capable developers use AI to mask skill gaps, implementing solutions they neither understand nor can modify. When these implementations fail, they lack the knowledge to fix them independently.

This widens the skill gap. Top engineers leverage AI for mechanical tasks while focusing on higher-value thinking. Those using AI as a substitute for learning face limitations when working beyond the AI's knowledge boundaries.

A good example of something that AI is perfect for is translation logic:

Let’s say I have Python Dataclass representing an" “InternalUser”. I also have a Django ORM representation of the same entity. If I wanted to convert one to the other, I can just paste both representations in to ChatGPT and get it create me a conversion function. Notice that the conversion function also takes into account that the field names aren’t exact matches:

@dataclass
class InternalUser:
    id: str
    email: str
    hashed_password: str
    full_name: str
    role: UserRole
    status: AccountStatus
    created_at: datetime
    updated_at: datetime
    address: Optional[Address] = None
    preferences: Preferences = field(default_factory=Preferences)
    login_activity: LoginActivity = field(default_factory=LoginActivity)
    tags: List[str] = field(default_factory=list)
    notes: Optional[str] = None

class InternalUser(models.Model):
    id = models.CharField(primary_key=True, max_length=100)  # Use UUIDField if preferred
    email = models.EmailField(unique=True)
    hashedPassword = models.CharField(max_length=256)
    fullName = models.CharField(max_length=255)
    role = models.CharField(max_length=20, choices=UserRole.choices, default=UserRole.USER)
    status = models.CharField(max_length=20, choices=AccountStatus.choices, default=AccountStatus.PENDING)
    createdAt = models.DateTimeField(default=timezone.now)
    updatedAt = models.DateTimeField(auto_now=True)

    address = models.OneToOneField(Address, null=True, blank=True, on_delete=models.SET_NULL)
    preferences = models.OneToOneField(Preferences, on_delete=models.CASCADE)
    loginActivity = models.OneToOneField(LoginActivity, on_delete=models.CASCADE)

    tags = models.JSONField(default=list, blank=True)  # List of strings
    notes = models.TextField(null=True, blank=True)

    def __str__(self):
        return f"{self.fullName} ({self.email})"

from typing import Optional
from myapp.models import InternalUser as ORMInternalUser, Address as ORMAddress, Preferences as ORMPreferences, LoginActivity as ORMLoginActivity
from mydataclasses import InternalUser as DCInternalUser  # assuming your dataclass lives here


def convert_internal_user_to_model(dc_user: DCInternalUser) -> ORMInternalUser:
    # Create or update Address if provided
    orm_address: Optional[ORMAddress] = None
    if dc_user.address:
        orm_address = ORMAddress.objects.create(
            street=dc_user.address.street,
            city=dc_user.address.city,
            state=dc_user.address.state,
            postalCode=dc_user.address.postal_code,
            country=dc_user.address.country
        )

    # Create Preferences
    orm_preferences = ORMPreferences.objects.create(
        newsletterOptIn=dc_user.preferences.newsletter_opt_in,
        darkModeEnabled=dc_user.preferences.dark_mode_enabled,
        language=dc_user.preferences.language
    )

    # Create LoginActivity
    orm_login_activity = ORMLoginActivity.objects.create(
        lastLogin=dc_user.login_activity.last_login,
        loginAttempts=dc_user.login_activity.login_attempts,
        lastIpAddress=dc_user.login_activity.last_ip_address
    )

    # Create InternalUser
    orm_user = ORMInternalUser.objects.create(
        id=dc_user.id,
        email=dc_user.email,
        hashedPassword=dc_user.hashed_password,
        fullName=dc_user.full_name,
        role=dc_user.role.value,
        status=dc_user.status.value,
        createdAt=dc_user.created_at,
        updatedAt=dc_user.updated_at,
        address=orm_address,
        preferences=orm_preferences,
        loginActivity=orm_login_activity,
        tags=dc_user.tags,
        notes=dc_user.notes
    )

    return orm_user

This is a basic example, but extrapolate this out to an entire internal data model and you’ve saved hours and hours of code.

You can even then ask it to create you the function stubs of the tests:

import pytest
from datetime import datetime
from yourmodule.dataclasses import InternalUser, Address, Preferences, LoginActivity, UserRole, AccountStatus
from yourmodule.conversion import dataclass_to_django_internal_user


@pytest.mark.django_db
def test_internal_user_conversion_basic_fields():
    # Test that basic fields (email, name, etc.) are correctly copied
    pass


@pytest.mark.django_db
def test_internal_user_conversion_with_address():
    # Test that address fields are properly mapped to the ORM model
    pass


@pytest.mark.django_db
def test_internal_user_conversion_with_preferences():
    # Test preferences like dark mode, newsletter opt-in, and language
    pass


@pytest.mark.django_db
def test_internal_user_conversion_with_login_activity():
    # Test login attempts, last IP, and last login datetime
    pass


@pytest.mark.django_db
def test_internal_user_conversion_with_tags_and_notes():
    # Test tags list and optional notes field
    pass


@pytest.mark.django_db
def test_internal_user_conversion_with_missing_optional_fields():
    # Ensure None fields like address or lastLogin don’t break conversion
    pass


@pytest.mark.django_db
def test_internal_user_conversion_saves_correctly():
    # Save all related models and main InternalUser model and check database
    pass

Now, I’m not suggesting that you take these as is and don’t add your own thought in to each possible test scenario, but it’s a great start.

These pieces of “grunt work” were never what we paid the top engineers for. These were just the things that they had to do to get the job done. People didn’t enjoy these tasks. They weren’t fulfilling.

Critical Skills for the AI Era

As AI handles more coding tasks, successful engineers must develop strengths in areas where human judgment remains essential:

Systems thinking becomes the primary skill – understanding component interactions, identifying potential failures, and designing for future growth. This capability comes from experience, not prompting.

You should build expertise in infrastructure and deployment processes. Software that works in development but fails in production creates no value. So, learn about continuous integration, monitoring systems, and cloud platform capabilities.

You should also master API design – the interfaces between systems. Well-designed APIs enable team independence. Poor interfaces create bottlenecks affecting everyone.

Another key skill is being able to integrate security throughout the development process. A single oversight can result in breaches, damaging both customer trust and business standing.

Make sure you develop communication skills for both technical and non-technical audiences. You’ll need to explain complex decisions clearly across different stakeholder groups.

And study how AI tools function to understand their limitations and strengths, allowing you to use them most effectively.

For senior developers, mentoring becomes increasingly important. New engineers need guidance on responsible AI usage – knowing when to accept suggestions and when to question them.

The Path Forward

The software field is entering a significant transition. AI will generate more code more quickly, transforming development practices. This shift presents both opportunities and challenges.

The most valuable positions will go to those good at tasks machines cannot handle. These engineers will determine what to build, how to design it, and how to balance technical constraints with business objectives.

"Vibe coding" serves as a useful technique for specific needs – like quickly building standard components. But it fails as a comprehensive strategy for complex system development.

Skilled engineers will advance by delegating routine work to AI while addressing more challenging problems. Less skilled engineers will struggle as fundamental knowledge gaps become apparent.

With regards to learning how to use AI effectively, also use caution and judgement when following advice from people online. It’s still a fairly new field and changes constantly.

People online are giving away “free prompts” to generate code. These prompts may be great or may have problems. The prompts may have worked when they used them, but the AI models may have changed and maybe they’ll produce different results now. Be cautious and use your best judgement.

The future belongs to those who view AI as a collaborative tool rather than a replacement. Software development remains fundamentally human-driven, now supported by increasingly powerful assistance.

In his spare time, Ben writes his tech blog Just Another Tech Lead and runs a site on SEO, SmoothSEO.

I’ve been participating and running Sprint Retrospectives now for 15 years and I truly believe that when done well, they are the best way to make a team more effective and more closely bonded.

What is a Sprint Retrospective?

A sprint retrospective is one of the key events in an Agile Sprint. The retrospective occurs at the end of each sprint and it is the meeting where the scrum team gets together to talk openly and honestly about the sprint that has just finished.

The purpose of the Sprint Retrospective is to find out things that went well in the previous sprint and things that didn’t.

Agile promotes iteration and improvement. The retrospective is a way to continuously improve the team and the team’s practices by regularly (at the end of each sprint) dissecting your working practices and trying to improve upon them.

Building the Foundation for Effective Retrospectives

Before diving into methodology, let's address three critical factors that determine how successful your sprint retrospective might be:

1. Team size matters: I've discovered that scrum teams larger than 6-7 people struggle with meaningful retrospectives. The dynamics change, people speak less freely, and you lose the intimate environment needed for honest feedback. If your team has grown too large, consider splitting it.

2. Trust is non-negotiable: I've seen brilliant retrospective frameworks fail in environments where team members don't feel safe sharing honest feedback. This foundation must be established first.

3. Actions speak louder than words: Teams quickly recognize empty exercises. If retrospective outcomes aren't implemented, people will lose faith and stop participating. Make sure you follow through.

The Mechanics of Start, Stop, Continue

The beauty of this approach is due to its simplicity.

Start, Stop, Continue is a framework that tries to get you and your team to categorize all of the aspects of work in the team (planning, execution, reviews, communication, and so on) into three simple categories:

• Things we should start doing (before starting a new code change, see if there are open pull requests to review),

• Things we should stop doing (submitting pull requests that are longer than X lines), and

• Things we should continue doing (keep the stand up to 15 minutes).

Here's how I structure these sessions:

Gathering "Start" Items

I ask: "What practices should we begin implementing that we currently don't do?"

Common themes I've seen across teams include:

• Earlier stakeholder demos

• More rigorous code review practices

• Better preparation before refinement meetings

• Cross-functional pairing opportunities

• More well-defined tasks

Finding the "Stop" Items

Next question: "What's currently slowing down our productivity or quality?"

Frequently mentioned items include:

• Context switching between multiple stories

• Late-sprint testing bottlenecks

• Inconsistent documentation practices

• Meeting overload

• Changing priorities mid sprint

Recognizing "Continue" Items

Finally: "What positive practices have we recently adopted that require reinforcement?"

This category functions as a temporary holding area. Once practices become second nature, they graduate from the list.

The Decision Framework

After generating ideas, decision-making becomes critical.

You now need to decide which items on the board (across all categories) you want to talk about.

There may be some retrospectives where you decide as a team that the most important items to talk about are all In the “start” category, there may be some meetings where you talk about items from the Start, Stop, and Continue categories. It really depends on what is deemed by the team to be the most important items that need addressing.

Here’s my preferred approach to picking the most important topics to discuss:

1. Group similar items for clarity. Are there three items on the board that are to do with different aspects of stability? Group them into one.

2. Allocate three votes per team member. Giving people limited options means that their votes truly matter. If you ask people to tag any items they see as important, you’ll more than likely get an overwhelming number of action items.

3. Select the top 2-3 items for action. It’s not possible to make too many changes in one go or in one sprint. Choosing 2-3 means that you are likely to be able to achieve them. Starting each retro by highlighting missed action items can be demoralizing. Limiting your action items hopefully mitigates this.

4. Assign clear ownership for each item. One person needs to lead each action item. Without clear ownership, the bystander effect is likely to happen.

The key insight: changing too many things simultaneously dilutes focus. A few well-implemented changes outperform numerous half-hearted attempts.

Avoiding Retrospective Monotony

Repetitive formats lead to diminishing returns.

There are various ways that you can “spice up” the Start, Stop, Continue framework to make sure that people don’t get bored and just go through the motions.

Some of the processes below augment the Start, Stop, Continue process changing it slightly to keep it interesting.

I've developed several variations to keep the process engaging:

• Silent brainstorming: Everyone writes ideas on sticky notes before sharing

• Theme-focused: Concentrate on specific areas (for example, "testing practices" or "collaboration"). Only do Start, Stop, and Continue on the chosen topic.

• Data-driven: Begin by examining sprint metrics, then discuss implications. Look at the sprint burndown, the velocity, the story breakdown and do Start, Stop Continue based on the data that you see. For instance, “Start breaking stories down to smaller chunks so that each story can be delivered quicker giving us a more smooth burndown”

• Rotating facilitation: Have different team members lead each retrospective. People engage more if they are actively leading a meeting. They will find ways to keep the others engages as well as they want to do a good job of running the meeting.

• Talking stick: Use a physical stick (yes, I’m serious) as a talking stick and only the person holding can talk. They are allowed to talk about whatever they want, good, bad, or indifferent. You can have one person taking the notes of what the person with the talking stick is saying. For instance, the person with the talking stick might say "I’d like to reduce the number of project meetings within the Sprint”. The meeting facilitator could then translate this to “Stop having so many project meetings in the sprint” and put it on the board.

The Mathematics of Team Improvement

Here's something rarely discussed in Agile circles but frequently mentioned in finance: the power of compounding. Just as compound interest transforms modest savings into significant wealth, small team improvements compound over time.

Consider this: A team implementing just one meaningful improvement per sprint will see huge results after a year. If each improvement increases efficiency by just 2%, the compounding effect after 26 two-week sprints is remarkable.

Teams that understand this principle outperform those making sporadic large changes.

Maintaining Continuity Between Retrospectives

I maintain a living document tracking all retrospective outcomes.

Before each new session, I review:

• Which items were successfully implemented

• Which items need continued attention

• Which items were dropped and why

This creates an improvement narrative that demonstrates the team's evolution.

Why This Framework Delivers in Real-World Scenarios

Having implemented this across multiple organizations, from startups to established enterprises, I've found the Start, Stop, Continue model succeeds because:

1. It creates immediate clarity on what requires action

2. It balances recognition of successes with acknowledgment of challenges

3. It creates a sustainable improvement cycle without overwhelming the team

4. It focuses on behavioral changes rather than vague aspirations

The best retrospectives I've facilitated didn't just improve processes—they transformed team cultures by establishing continuous improvement as a fundamental value.

In his spare time, Ben writes his tech blog Just Another Tech Lead and runs a site creating forever-free online calaculators at CalculatorLord.com.

When done right, the Sprint Review can be key to keeping your project on track. But badly run Sprint Reviews are worse than just the time they waste – they also reduce people’s trust in Scrum as a whole.

In this article, I’ll walk you through some clear, step-by-step ideas for making your Sprint Review more valuable.

What is a Sprint Review?

A Sprint Review is a short session held at the end of each sprint, usually once every couple of weeks.

It allows the team to show what they have completed via demos, get feedback, and decide what happens next.

When run well, the Sprint Review shows progress and builds trust with the people who have a stake in the product and project.

Sure, you can tell the stakeholders you are on track, but if they can see it with their own eyes in the Sprint Review, they’ll be much happier.

Who Should Be in the Review?

In short, anyone who wants to be. Anyone who is a project stakeholder in any capacity can and should attend the meetings.

The scrum team themselves are the core of the meeting, but there can also be Sales, Senior Management, other scrum teams, and Project Managers.

In short, if someone could have good input on a project or could get something out of learning something about a project, they should attend.

What to Do Before the Review

To ensure that the meeting itself runs as smoothly as possible, you need to make sure that everyone presenting is ready and has a demo ready to show.

In my experience, live demos don’t work. Well, sometimes they do, but mostly they don’t.

Get the people who have a demo to at least record themselves showing their workflow prior to the meeting. That way, if they insist on doing a live demo, they have a recorded video as a backup if it goes wrong.

You should also have a running order. Know who is presenting, in which order, and group them by similarity of topic. Who presents and when doesn’t really matter as long as the presentations are grouped together by topic.

For instance, if you have six engineers – two working on a Login Page, two working on new back-end service, and two working on database performance – make sure that your running order groups these three distinct areas together.

If two demos are fairly similar, you can explain the context once and then run through both demos back to back. Be efficient, as you have a lot of people in this meeting and everyone knows that meetings are expensive.

During the Review

The Software Engineers who have completed a piece of work will present the work to the other members of the scrum team (Product, QA, and so on) as well as all stakeholders who have attended.

After each Engineer has presented, anyone in the room is free to either ask questions or make comments about the work/presentation.

These questions can simply be to fill in knowledge gaps for people who know less about the project, or they can be questions about why a particular solution was chosen.

Product or more business-focused members of the audience may now give feedback on whether what was demonstrated matches the business intent of what was asked to be delivered.

Once all questions and comments have been addressed, the next Engineer will present their work.

In a Sprint Review, everyone is encouraged to speak, but generally it’s only Engineers who present. So the Engineer will present what they have worked on, then Product, QA, BA, and so on can give feedback and ask questions specifically about what the engineer has presented.

Example Review

Let’s take a look at an example review and what that may look like.

We’ll use the example above of having six engineers: two working on a Login Page, two working on a back-end service, and two working on database performance. In that case, you may have a running order like this:

Presentations:

1. Larry: User Exceeds Max login attempts and the user account gets locked after the fifth incorrect password. User has to reset password before they can login again.

2. David: User clicks forgotten password link and a link is sent to their email address. The user follows this link and is able to reset their password.

3. Premilla: Reporting Service consumes the “User Exceeded Max Login Attempts” event and publishes it to the reporting dashboard.

4. Akshat: Reporting Service consumes the “User Clicked Forgotten Password” event and publishes this to the reporting dashboard

5. Olga: An Admin User can view the reporting dashboard for a month and load the report within 3 seconds.

6. Trevor: An Admin User can view the events from multiple users combined in to one dashboard and load the report within 2 seconds.

As you can see here, the two login page user stories are demonstrated first, then the two reporting service stories, and then the two database speed stories. This requires less context switching for the members of the audience and means that context only needs to be given at the beginning of the first of the two grouped stories (that is, presentations 1, 3 and 5).

After presentation 1 (by Larry), Product may ask why he chose 5 retries as the maximum amount of retries before locking the account. Larry may have an answer, or he may not. Product can either ask to have a follow up on this later and find out what the industry standard is and apply that to Larry’s logic, or just leave it as it is.

After each of the six presentations, there could be questions, comments, and change requests by anyone in the audience. Typically this will then spark a conversation amongst the audience about the best approach.

For instance, in Larry’s example again, some may argue that they should not even be using a username and password, but instead should use an email address and magic link. This is the beauty of the review. You have a lot of smart people in a room bringing their own experience and expertise.

Actionable Takeaways

Here are some tips for what to show, how to show it, and what actually matters during the meeting itself.

1. Showcase Real Deliverables

First, always present working software or completed work rather than static slides. For instance, if you built a new login feature, do a live demo. This makes the review more genuine and shows tangible progress.

2. Encourage Open Feedback

Second, invite questions from everyone. Remind stakeholders that their ideas can help shape future work. Write down their suggestions, and confirm whether any changes should go straight into your backlog.

3. Keep It Clear and On Track

Third, maintain a simple format. For example, start with a quick overview of the sprint goal, move to demos, and end with a short discussion of next steps.

Avoid going too deep into technical details. If a topic needs more time, set up a follow-up chat.

4. Align on Next Steps

After that, update your backlog based on what you learned. If a feature needs an extra tweak, add that task right away.

This helps the entire group stay informed about the plan for the upcoming sprint.

5. Keep it short and end on Time

You should be reviewing one scrum team’s work for one sprint (two or three weeks).

If your meetings are running on for too long, it either means that your scrum team is too large (in which case, you should think about splitting your scrum team into smaller teams), or you are not efficient enough with your demos.

People’s time and attention is expensive and in short supply. Keep the meetings to no more than one ultradian cycle. I personally try to limit all of the meetings I run to a max of 90 minutes.

Lastly, set a firm limit for the meeting so that participants feel confident bringing their feedback without dragging out the discussion.

Wrapping up on time respects everyone’s schedule and keeps the team fresh for the next sprint.

In Summary

A Sprint Review gives stakeholders a real-time look at completed work, ensures alignment on what’s next, and gathers the feedback you need to grow your product effectively.

If you focus on showing real progress, inviting open dialogue, and keeping things concise, you’ll see a steady improvement in how your team delivers.

In his spare time, Ben writes his tech blog Just Another Tech Lead and runs a site creating forever-free online calaculators at CalculatorLord.com.

If you work on a Scrum team, you’ve probably heard of a daily scrum, sometimes called a daily stand-up. It’s one of the key events in scrum.

The “daily” usually takes place around the same time every day, and it should last around 15 minutes.

At first glance, it seems straightforward. When it’s your turn, you answer three basic questions. Job’s done, right?

Well, without a structure and someone to enforce that structure, a 15 minute daily meeting can turn in to a 45 minute chat.

What Is the Daily Scrum?

Scrum teams use the daily scrum to align and share their efforts.

Each person usually answers three questions:

1. What did I do yesterday to help the team meet its goal?

2. What do I plan to do today to help the team meet its goal?

3. Are there any obstacles in my way?

I call these the “classic three.” Yesterday, Today, Blockers.

From this explanation, if you’ve never attended a daily scrum, you might assume it’s just a trivial and pretty pointless meeting. But it can highlight important issues in real time.

For instance, if someone says, “I’m stuck waiting for a database script to finish,” the rest of the team can suggest a workaround.

Or if the product owner says, “We need to shift a feature’s priority,” everyone learns about it immediately.

Why Keep the Scrum Short?

In theory, the daily scrum lasts 15 minutes, give or take. Yet, many teams allow it to stretch to half an hour or more.

That’s risky.

When these meetings grow too long, people lose interest. Also, they might skip the next one, feeling like it’s a waste of time.

Beyond this, brevity encourages people to share only what matters most.

If someone dives into intricate details, it might derail the conversation.

This is not the space for describing every table in your database schema. It’s a moment to share your progress, highlight your plan, and let your teammates know if you’re blocked.

The Three Essential Questions

The daily scrum usually follows the same pattern. It’s predictable, and that’s a good thing.

Let’s expand on each question:

1. Yesterday’s Tasks: This is an update on what you finished. For instance, I might say, “I set up the new testing environment for our user login feature.” That helps the rest of the team see how tasks are progressing and whether I’m finishing my part of the sprint goal.

2. Today’s Plans: Next, we share what we’re about to tackle. For example, “Today, I’m going to fix a bug in the payment service.” That piece of information helps everyone see how the day’s work lines up with the sprint backlog.

3. Blockers: This is a crucial point. If something is stopping me from completing my tasks, I mention it here. Let’s say, “I need access to the staging environment, but I’m waiting on a permissions update to give me access.” This means if anyone on the team can fix that, we speed up progress.

In my teams, we usually have the Jira board open and associate each person’s update with the related story. This gives people a little more context. You don’t have to do this though – my teams just find it helpful.

How to Prevent the Scrum from Turning into a Status Meeting

A daily scrum is not just a status report. It’s a chance for the team to realign quickly.

But some managers treat it as a time to see who is on track. That can shift the focus away from cooperation. On the other hand, a team might treat it like a casual hangout without any structure. These extremes usually lead to frustration.

What’s the sweet spot?

It’s where the team focuses on tasks that lead to the sprint goal while also offering quick help when people get stuck.

The meeting should be about collaboration and the scrum team’s needs, not about pleasing a manager.

Also, if something requires a deeper talk, schedule a follow-up. For instance, you might say, “Let’s finish the stand-up, then we can chat about the modeling question after”.

If you find that your stand ups are getting too long, you as a team need to discuss why this is happening in the sprint retro and adjust.

A Typical Example of a Smooth Daily Scrum

Let’s paint a quick picture.

The team is working on a feature that handles user registration and payment processing. Each day, the daily scrum goes like this:

1. Developer A:

   • Yesterday, I cleaned up the user registration form.

   • Today, I’ll add form validation for email.

   • I’m blocked by a missing API key, so if someone can share that, I can move forward.

2. Developer B:

   • Yesterday, I tested the payment integration.

   • Today, I’ll fix a bug I found during testing.

   • No blockers.

3. QA Engineer:

   • Yesterday, I automated tests for the cart service.

   • Today, I’ll check the new user registration form.

   • No blockers, but I want to set up a quick chat about test coverage soon.

The entire process finishes in around 10 minutes. After the scrum, Developer A and Developer B might stay behind to swap that missing API key. Everyone else dives into their day. That’s it—short, sweet, and useful.

Common Problems That Disrupt the Daily Scrum

Let’s discuss a few pitfalls I’ve seen crop up over the years:

1. Going off on tangents: For instance, a developer might begin describing the entire architecture of a new microservice. The rest of the team is left wondering how that affects them.

2. Trying to solve every issue in real time: The daily scrum is not the place to debug code or solve other issues as a group. If something complex needs discussion, note it and talk after the stand-up with the interested parties.

3. Waiting for latecomers: Starting late can quickly become a habit. If people learn that the meeting really begins at 9:05, they start arriving at 9:10. The easiest fix is to start on time. People usually adapt once they see you’re serious.

4. No one mentions blockers: Sometimes, folks feel uncomfortable admitting a problem in front of the team. If that happens, the daily scrum loses its value. This meeting is precisely where you should feel safe to say, “I’m stuck here.”

5. Too many people in the meeting: In certain organizations, multiple teams join one daily scrum. That can lead to confusion. It’s better to keep each daily scrum small and focused. If you have a big project, you might break out into smaller Scrum teams.

Tips for Keeping the Meeting on Track

There are various ways you can help keep a daily scrum from devolving into a long, drawn-out meeting.

First, make sure you stick to 15 minutes (or shorter). A timer can really help. Some teams use an actual countdown on a screen, which can be fun. If you find that it’s consistently longer, it may be a sign that you have too many people, your team members need reminding about the format, and so on.

Second, make sure you have a capable leader who understands how to manage the scrum. Often, the scrum master or team lead can step in if the conversation strays. They might say, “Good point. Let’s park that for later.” This ensures the scrum doesn’t balloon into a brainstorming session.

You should also make sure the team is focusing on its sprint goals during the meeting. In addition to sharing tasks, remember why you’re doing them. For instance, if you know the sprint goal is to launch a new checkout flow, keep that in mind. This will help streamline everyone’s three questions.

Next, make sure you promote a culture of help. If someone mentions a blocker, invite the group to see who can help. This is a practical approach that fosters teamwork.

And finally, it can be helpful to use the scrum board. This board—whether physical or digital—helps people visualize progress. If your tasks are on sticky notes or in a tool like Jira, you can quickly show which tasks are done, in progress, or awaiting review.

Practical Ways Managers Can Support the Daily Scrum

Some folks ask if managers should attend the scrum every day. There’s no strict rule, but if you do join, here are some things to keep in mind to help your team stay on track.

First, make sure you let the team speak. The daily scrum is for the development team to share their plan and blockers. You as a manager should avoid turning it into a performance check.

Next, try to observe any ongoing or developing patterns. The manager can spot trends. For instance, if a certain issue keeps popping up, they might escalate it or allocate more resources toward solving it.

And try to offer help without dominating the meeting. The moment you sense a roadblock your position can solve—like a missing budget approval—step in. Otherwise, let the team own the meeting.

Frequently Asked Questions

1. How strict is the 15-minute rule?

   Pretty strict if you can help it. If your team is small, you may finish in even less time.

2. Do we need to stand physically?
   Some say it keeps the meeting short. Others aren’t able to stand, or prefer to sit. In my teams, the goal is brevity, so sitting or standing doesn’t matter as much. We also usually have a hybrid stand up where some people are in the office and some aren’t. For this, we all attend virtually.

3. What if we have nothing new to say?
   That’s fine. A quick “No updates, no blockers” is perfectly acceptable. The meeting might take only five minutes. Great—everyone can get back to work sooner.

4. Do we ever skip the daily scrum?
   Some teams do skip if everything is stable. I never do though, because it confirms that no new blockers have emerged. It’s like a brief pulse check. If there’s nothing to share, the meeting won’t last long anyway.

5. Who speaks first?
   Some teams pass a “talking stick” around in a circle. Others follow the order of tasks on the board. I’ve even seen teams do it alphabetically. I also like to mix it up by playing the “nomination game” where the person speaking nominates the next person. The method doesn’t matter, as long as everyone gets a turn. I do like to mix the ordering up though as it keeps the meeting a little “fresh”.

Conclusion

The daily scrum can be one of the most helpful parts of Scrum if it’s done right. It helps with open communication, early detection of blockers, and a sense of shared ownership.

Also, it reminds us what we’re aiming to achieve as a team (the sprint goal), which is easy to forget when everyone’s heads are down coding or testing.

Above all, keep it simple. Focus on yesterday’s progress, today’s plan, and any obstacles in your path.

If you need deeper conversations, schedule them right after the scrum with the people who care most about the topic. That way, you respect everyone else’s time.

In his spare time, Ben writes his tech blog Just Another Tech Lead and runs a site creating forever-free online calaculators at CalculatorLord.com.

I’ll take you through what user stories are, common pitfalls that I’ve seen with creating user stories, and the frameworks that exist to validate if your user story is “good”.

Here’s what we’ll cover:

• The beginnings of Agile

• What is Agile?

• What is a User Story?

  • Structure of a User Story

  • Example of User Stories

• How to make good User Stories

• Common pitfalls in User Story creation

  • Focusing on the technical aspects

  • Stakeholder Collaboration

  • Vague User Stories

• How to begin with User Stories

• Conclusion

The Beginnings of Agile

Chances are that you’ve heard of Agile Development and User Stories. But if you haven’t, let’s have a brief history lesson:

User Stories are part of a larger concept called Agile methodologies.

Agile methodologies have been around since 2001 when 17 well-respected software engineers met at a Ski resort in Utah and created the now infamous Agile Manifesto.

If names such as Robert Martin, Martin Fowler and Kent Beck don’t mean anything to you, once you’ve finished this article, go and search them out. They have a wealth of knowledge and between them gave the world of software a more fluid way of delivering projects, called Agiile.

What is Agile?

Agile is more of a way of thinking than a prescribed method. Prescribed methods exist, such as Scrum and Kanban, but Agile is a concept.

Agile promotes collaboration, fast feedback, and delivering value often to the user.

The Agile way of thinking encourages flexibility in project planning, which is in stark contrast to its competitor at the time, Waterfall project planning, which was very rigid with what was being delivered and when.

Agile methodologies promote doing “just enough” research at the beginning to get the project started, and then learning, iterating, and changing the design and deliverable as needed throughout the project until the final code is delivered. This “change and learn as you go” approach is called “adaptive planning”.

Agile promotes delivering something of value quickly and often, usually in the form of delivering code to production at the end of every two week “sprint”. This, again, is very different from traditional waterfall planning which would often require months of development before any user-visible change could be delivered to production.

Another key part of Agile is the focus it puts on stakeholders working together closely and often. Product, QA, Engineering, and Sales all have a large input and constant feedback on the project through the project lifecycle.

Now that you know a bit more about how Agile works, let’s dive deeper into how we validate value to the user.

Enter the User Story.

What is a User Story?

A user story is way in plain English to connect the engineer to the end goal of the software.

It’s designed so that a non-techy can read it and understand what is being delivered, and so that an engineer can look at it and see the value and how to validate that you’ve delivered that value.

Structure of a User Story

As a [type of user], when I [perform action], [expected outcome]

At its most basic, that is it.

You are putting the emphasis on the end user and the “value” that you will deliver.

Let’s dig into the inputs:

• Type of user: There is no one size fits all “user”. You have “admin users”, you have “logged-in users”, you have “users with permission X” or “users in role Y”. This is being specific about who is performing the action

• Perform action: What is the user doing? Clicking the “login” button? Deleting a record? Submitting a form?

• Expected outcome: Once your user has performed the action, what should happen? If they’ve clicked “login” with the correct email address and password, where should they be directed? If they’ve clicked “login” with an incorrect email address and password, what should happen?

Example of User Stories

Let’s look at examples of user stories for a login page.

There’s nothing better than examples.

Let’s set the scene. You have a login page with an entry text box for an email address and an entry text box for a password. You have a submit button. That’s it.

What are the different permutations that can happen on this page from the user’s perspective?

As a logged in user, when the page loads, I am redirected to the logged in home page

If I’m already logged in, I don’t want to have to reenter my details, just redirect me to the logged-in home page.

As a non logged in user, when I enter the correct email address but incorrect password and click Login, an error message appears

I’m a user who’s not already logged in, and I entered the incorrect details. I should not be logged in.

As a non logged in user, when I enter an incorrect email address and password and click login, an error message appears.

Again. I’m not a logged-in user. I’ve entered incorrect details, I should not be logged in.

As a non logged in user, when I enter the correct email address and password and click login, I am rediected to the logged in home page.

This time, I’m not already logged in, I enter the correct details and click login. I’m logged in to the system.

Can you see how all of these are focused on the user?

You may notice that some of the “expected behaviour” in the above is not fully defined. We’ll address that later in the acceptance criteria.

How to make good User Stories

There’s a good model called the INVEST model that really simply shows how to know if your user stories are good.

INVEST Model:

• Independent: Can be developed separately.

• Negotiable: Open to discussion and change.

• Valuable: Delivers value to the user.

• Estimable: Can be estimated for effort.

• Small: Fits within a sprint.

• Testable: Has clear acceptance criteria.

Let’s apply this INVEST model to one of the user stories examples from above:

As a non logged in user, when I enter the correct email address and password and click login, I am rediected to the logged in home page.

(I’m going to make some assumptions here, as this is a theoretical code base and theoretical project)

Is this story Independent? I would say so, yes. It’s a small story that involves only a few components that probably already exist. If the database hasn’t been created yet though for the project, that would give us a dependency. This would no longer be independent.

Is it Negotiable? Well again, yes. This story could easily be changed to redirect to the users profile page rather than their home page.

This story is definitely valuable. Once implemented, the user can log in. If the story was:

As a non logged in user, when I enter the correct email address and password and click login, nothing happens

This would not be valuable. The user would get nothing out of this.

Is the story estimable? Again, we have to take some assumptions in this made up scenario, but I would certainly hope that this would be easily estimated. It’s a concise story, involving few components, in a domain that everyone is familiar with and has clear acceptance criteria.

The story is certainly small. There is little ambiguity in what needs to be done, there is one user path only and clear outcomes. Let’s take a look at a story that would be too large:

As a non logged in user, the login page should work as expected.

As discussed further up in this article, there are many ways that the login page can and should work. “Should work as expected” seems to cover all of those permutations. This would be too large to effectively size as a story, and probably too large to be completed in one sprint.

The story is definitely Testable. There are clear user actions to take that has a clear outcome. This user story can be covered by Unit Tests, Integration Tests, and Manual Tests.

It looks like we’ve created a good user story!

If you use the structure I’ve defined above, and the story meets the criteria of the INVEST model, it’s probably a good story.

Common pitfalls in User Story creation

I’ve seen User stories go wrong in the past where people have missed a few crucial aspects to the user story:

Focusing on the technical aspects

As my examples show above, the user story is non-technical.

There should be no reference to a service name, a database name, or validation based on anything that the user can’t see.

As soon as your story is no longer able to be understood by the end user, you’ve gone wrong.

Focus on what the user is going to do, and what the user is going to see.

Let’s look at an example of a technically focused story:

As a non logged in user, when I click the forgotten password link with a correct email address, a record is logged in a database table stating that the password reset link has been sent.

This story can not be verified by a user and non technical users may not understand what it means.

Let’s fix it:

As a non logged in user, when I click the forgotten password link with a correct email address, an email is sent to the email address provided with a forgotten password reset link

Non technical users can understand this and it puts the focus on the user, not the product.

Stakeholder Collaboration

Agile is collaborative.

User stories need input from Product, BA, QA, Engineers, and most importantly, Users.

This is how you will ensure that you are delivering what the user wants. Many hands make light work.

If, for instance, just an engineering team came up with user stories, they may look something like this:

As a logged in user, when the page loads, I am redirected to the logged in home page

As a non logged in user, when I enter the correct email address but incorrect password and click Login, an error message appears

As a non logged in user, when I enter an incorrect email address and password and click login, an error message appears.

And that’s great. But now let’s get QA involved, who are coming from a different perspective as they’ve different experiences with software:

As a non logged in user, when I enter a correct email address in Hebrew and a correct password, I am redirected to the home page

As a non logged in user, when I enter a correct email address and password and repeatedly click login, I am redirected to the home page

Great. We’re getting a more rounded set of user stories now that cover more situations. But what happens if we get Product involved?

As a non logged in user, when the page loads, my password manager should pre-load my username and password, when I click login, I am redirected to the home page

The Product team know the users. They know that people really use password managers. We should make sure that when the user doesn’t actually type anything (as the text is loaded by the password manager), the login still works correctly.

Vague User Stories

The idea behind a good user story is that everyone, regardless of expertise, can understand it.

If you’ve written a User Story that. can be interpreted 10 different ways by 10 different people, you’ve gone a bit wrong.

I mentioned above that I would touch on acceptance criteria, and now is the time to do that.

Let’s re-examine the following User Story:

As a non logged in user, when I enter an incorrect email address and password and click login, an error message appears.

There’s vagueness in there.

What message should appear? When the page reloads after an invalid login attempt, should the username text box be set back to empty, or prepopulated with the previously entered value? What does “incorrect email address” mean? An email address that has never been seen before, or an email address that is not valid at the moment (not paid the subscription, canceled subscription etc.)

So as you can see, details matter.

This User Story is a fairly contrived simple example and I’ve managed to find a lot of questions about it.

Let’s fix the problem:

As a non logged in user, when I enter an email address that it not registered with the system, when I click login, an error message appears

That removed the questions around the user action but has not resolved the issue about the expected error message.

Enter the acceptance criteria.

Within the user story, you need to have a set of acceptance criteria that defines if the implementation of the user story is as expected.

Things like:

• Error message: “Invalid email address or password”

• Email Address and Password text box reset to empty on reload

• User unable to access pages where login is required

• User is presented with a “forgotten password” suggested.

Acceptance criteria states what is expected from the implementation.

How to Begin with User Stories

Start small.

You will not be perfect at refining and creating user stories to start with.

Creating user stories is as much an art as a science. Practice makes perfect.

The creation of User Stories should be done as a group. Often, this is done with the “3 Amigoes” approach, where you will have an engineer, a product person and a QA all sit together and brain storm different permutations that you need to support.

Once you have delivered your project, retrospect. Take a look back and see what gaps you have in your user stories. There will be bugs that the users find, that QA and UAT find, and these are either due to gaps in your user stories or gaps in your testing. Either way, you should learn from them for next time.

Conclusion

Agile is collaborative. Scrum is collaborative. Creating User Stories is collaborative. Remember that.

The more people from different areas of expertise you have brainstorming user story creation, the more likely you are to cover the full set of workflows.

The user is the focus. If you are ever including terminology that your user doesn’t understand, rethink the user story.

You won’t be perfect at this from the start, but as you do more and more, the quicker and more effective you become. Take this from someone who has been doing this for over 10 years. The difference in speed and quality of my User Story creation today vs 10 years ago is a world apart.

In his spare time, Ben writes his tech blog Just Another Tech Lead and runs a site creating forever-free online calaculators at CalculatorLord.com.