Agile and DevOps in Practice

This session turns the DevOps theory you have already covered into a working walkthrough. You follow one Flutter application from the moment a client hands over a new project, through a full Scrum cycle managed in Jira, a code change committed to Git, an automated build in Jenkins, and the background scheduling that keeps everything running with cron jobs. Along the way you get the complete tool map of a DevOps engineer's daily work, so you know what each tool does, why it exists, and how the pieces talk to each other.

The route the session takes is the route a story takes: a client meeting decides the development model (waterfall or agile), a Scrum team turns that model into two-week sprints on a Kanban board, story points size the work, a burndown chart watches the sprint's health, Jira tracks every state change, Git stores and branches the code, Jenkins builds and tests it automatically, and cron jobs schedule the background work. By the end you will know not just what each tool does, but where it sits in the chain and which role owns it at each step.

5.1 The DevOps Tool Landscape

A DevOps engineer does not live inside one tool. The role spans the whole chain of taking code from a developer's machine to a running production service, and each link in that chain has its own set of tools. You are not expected to master all of them in one sitting — the practical sessions that follow this one cover each tool in turn — but you need the map first: what exists, which job each tool does, and where it sits in the process.

Think of the tool landscape as a production line with six stations: the operating system everything runs on (Linux), the network that connects machines (TCP/IP family), the scripts that automate work (shell scripts), the store where code lives (configuration management), the machines that build and ship it (integration and deployment), and the instruments that watch it in production (monitoring). Two more stations feed the line — testing tools and code-quality tools — and the DevOps engineer stands at the end of the line as the gate keeper.

5.1.1 Why Linux Is the Base

Every DevOps environment, whatever you are building, starts with Linux. Nobody builds a real-time deployment pipeline on a Windows server, and Mac is rare too. Linux is the default for two reasons. First, it is open source — free to use, free to inspect, and free to modify. Second, it gives you a huge ecosystem of tools, and because the source is open you can customize almost anything that your networking and deployment setup needs. If a standard package does not do exactly what your environment requires, you can change it. That level of control simply does not exist on closed platforms.

The practical consequence: the commands, scripts, and scheduling tools taught in this course (shell scripting, cron, Jenkins "execute shell" steps) are all Linux-world skills, and they transfer directly to any cloud deployment. Whatever the company's stack, the deployment layer underneath it is almost always Linux.

5.1.2 Networking Protocols: TCP/IP, HTTP, HTTPS, UDP

Since deployment is fundamentally about machines talking to each other, you also need the networking vocabulary. The protocols used for all of this networking come from the TCP/IP family — the professor actually misspoke at first and corrected himself to TCP/IP, so keep that name straight. TCP/IP (Transmission Control Protocol / Internet Protocol) is the underlying protocol suite everything else rides on. HTTP and HTTPS, the protocols your web applications speak, are part of TCP. UDP (User Datagram Protocol) is the other main transport, and it carries the video and audio protocols — streaming traffic, where losing the odd packet matters less than keeping up with real time. So HTTP, HTTPS, and UDP all sit on top of IP. You will see these in detail in later sessions, but the hierarchy is: IP at the bottom, TCP and UDP on top of it, and HTTP/HTTPS as TCP applications.

Visual intuition. Picture a layered cake: the bottom plate is IP (every packet gets an address), the next layer up has two halves — TCP on the left (checked, orderly delivery, like registered mail) and UDP on the right (fast, unregistered, like a postcard drop). On top of the TCP half sit HTTP and HTTPS, because web traffic wants guaranteed delivery; on top of the UDP half sit the streaming protocols, because a video that pauses to re-check one lost packet would freeze on screen.

5.1.3 Shell Scripting and Background Jobs

Whenever you need to start a process, create a cron job, or run any job in the background, you write shell scripts — small programs executed by the Linux command-line shell. This is how DevOps work gets automated: a script encodes the steps, and a scheduler runs it repeatedly. There are teams that operate on Windows, and for them the equivalent is a Windows batch file, but the overwhelming majority of the industry uses Linux shell scripting, so that is the skill to invest in.

5.1.4 Configuration Management and Version Control

Configuration management covers everything about storing, sharing, and tracking your code. The tool for this is Git, and around Git sit the hosting platforms: GitHub, GitLab, and Bitbucket. These all do the same core job — code repository access: uploading code, downloading code, and version control, meaning the ability to track history, create branches, and switch between versions of the codebase. Git, Bitbucket, TeamCity, and SVN all belong to this same configuration-management family. Jenkins technically builds code rather than storing it, but it is still grouped under configuration management in this tool map, because it consumes the repository and manages the build history.

5.1.5 Integration and Deployment

Version control and integration use the same family of tools. For deployment, Jenkins and CircleCI come in. Their job: take the code, build it, and push the result to whatever environment the project has — the automation environment, pre-production (preprod), UAT (user acceptance testing), or SAT (system acceptance testing). Whatever environments exist in your organization, the deployment tool moves the built artifact there.

5.1.6 Monitoring and Analytics

Once an application is running in production, you need eyes on it. If something goes down, if the load gets heavy, if there is unusual network traffic, or if a service stops responding properly, the analytics and monitoring tools tell you. They answer questions like: how much traffic is coming in, how many users are logged in, what is the concurrency limit, how many connections are connected to the server, what is the RAM usage, what is the processor usage, and how many VMs are attached. Named tools in this space include Google Analytics, Firebase, Prometheus, Grafana, and New Relic — there are many players, some open source and some licensed, and they can be integrated into the same pipeline. Real-world: Prometheus and Grafana together are a common open-source monitoring stack in production Kubernetes setups; New Relic is a commercial APM (application performance monitoring) product.

5.1.7 Testing Tools

Testing splits into many types — unit testing, regression testing, normal functional testing, performance testing, and security testing — and each has its own toolset. The unit-testing map looks like this: JUnit is for Java unit testing; Karma, Jasmine, and Cucumber are mainly for JavaScript-level and hybrid-environment testing; Mockito is for mock testing (simulating dependencies so you can test a component in isolation); and Selenium, plus what is labeled "APM" here, is for native testing of mobile or desktop system applications — the label is the tool Appium, the mobile test-automation companion to Selenium: Selenium drives web browsers, and Appium drives native mobile and desktop applications. The pair covers "click through the interface and check it behaves."

5.1.8 Code Quality and Linting Tools

Quality measurement is a separate category, and it is about catching code irregularity. A developer uploads code that has quality issues: a variable that is declared but never used, dead code after a return statement, unused functions, very big modules, a function longer than 50 lines of code, and sometimes even memory leaks. Linting tools scan for these problems. The map: Android Lint for Android applications, JS Lint and ES Lint for HTML-based applications, Swift Lint for iOS, Apache JMeter for Java-based applications, and Micro Focus LoadRunner for load testing.

5.1.9 The DevOps Engineer's Span

A DevOps engineer touches all of these areas — analytics, the CI/CD process, configuration management, scripting, networking, and testing and measurement tools — because it is the deployment engineer who runs these tools and reads their output. Based on success or failure of each stage, you either move the application to production or you stop the production release. That gate-keeper role is why the whole tool map matters: each future session dives into one of these tools, and this overview is the frame that holds them together.

Real-world & domain. This map is not academic — it is the actual daily toolset of deployment and site-reliability teams. Prometheus and Grafana form the standard open-source monitoring stack in production Kubernetes setups, New Relic is the commercial APM used for request-level performance, GitHub/GitLab/Bitbucket host the repositories, and Jenkins on-premises with CircleCI in the cloud are the CI/CD workhorses. The exam-relevant skill from this section is the map itself: for each tool, which category it belongs to — configuration management, deployment, monitoring, testing, or linting — because every practical session that follows builds on these categories.

5.2 The Sample Project and Solution Architecture

5.2.1 Why Flutter

To make every upcoming demonstration concrete, the running example is a Flutter application. Flutter is chosen because a single Flutter codebase compiles to Android, iOS, and web, and on the demo machine even macOS is available. So from one project you get one desktop system application, two mobile applications (Android and iOS), and one web application. Four targets, one DevOps process. You do not need to know Flutter itself — it will be explained in later classes — but it is the perfect vehicle for showing that the deployment machinery is identical no matter which platform you ship to.

5.2.2 The Client and Web Tiers

The overall solution architecture shows how an application is deployed and what the DevOps operations protect. At the front is the client tier — the end user's device running the app. Next comes the web tier, the security perimeter. Here you find the gateways through which push notifications arrive (this is how WhatsApp-style messages and other alerts reach your phone), firewalls, and load balancers — the devices that spread incoming traffic across many servers. This zone is also called the DMZ (demilitarized zone): the area where a lot of security protocols run, including reverse proxies and port tunneling. All the tunnelling, proxy, and firewall work happens in the web tier before any request is allowed deeper into the system.

5.2.3 The Application Tier

Cross the web tier and you reach the application tier, normally called the service tier. Multiple services run here for you, arranged behind further layers of security: external proxies and internal proxies, external management tools and internal management tools. Below all that sit the microservices — the individual services that actually deliver features: one for authentication, one for file management, one for role management, the Microsoft Office 365 applications such as email and Teams, a social media connector for Facebook and similar platforms, chatbot services, AR/VR and AI tools, and a security layer. All of these produce the data the end application shows.

5.2.4 The Data Tier and Three Kinds of Code

At the back sits the data tier: ERP tools, CRM tools, the basic database providers, office providers, and everything legacy. The architecture is a chain — client tier at the front, web tier, application tier, data tier — and each layer is protected by its own security mechanisms. From a deployment perspective, note that you ship three kinds of artifacts: the client code, the application code, and the database code. All three are deployed, and all three are part of the deployment architecture that later sessions dissect in detail.

Real-world & domain. The four-tier picture is the standard shape of enterprise deployments: the DMZ with firewalls, load balancers, and reverse proxies is exactly what sits in front of every bank, hospital, and SaaS platform; Office 365, social connectors, chatbots, and AI services are the real microservices inside modern service tiers; and the "three kinds of code" rule is why release engineering treats database migrations as first-class artifacts alongside binaries.

5.3 Waterfall versus Agile

A new project starts with a first meeting between your team and the client: what are we building, what is the timeline, how many sprints will it take, what is the team structure. One of the first decisions in that meeting is the development model: waterfall or agile. Modern software projects almost never choose waterfall. Agile is the default, but understanding why — and when the exception applies — is exactly the kind of judgment a DevOps engineer needs.

5.3.1 Where Waterfall Still Wins

Waterfall is the sequential model: requirements, design, implementation, testing, delivery, each phase finished before the next begins, on a long timescale — three months, six months, or more. It survives in places where you cannot change the product every two weeks. Military operations, for example: when you build large ships, aircraft, or weapons systems, you cannot revise the product every two weeks. The same logic applies to manufacturing and hardware: the physical production line cannot absorb weekly changes. So waterfall remains the traditional practice in manufacturing and retail hardware contexts.

5.3.2 Why Agile Wins in Software

Software is a volatile market, driven by people's reactions, and there agile wins for three reasons. First, you get faster processing and a small, working, testable increment of code every sprint — a viable product emerges within weeks, not months. Second, competition forces the pace: if two competitors are shipping new features to users every two weeks, you must ship on the same rhythm or lose the market. Third, and most important: unclear requirements are an automatic vote for agile. If the client is not clear about what they want, or is even doubtful themselves, waterfall is a trap — after six months of building, the client can say "this is not what we expected, we want something different," and you are facing a nightmare. With agile you show something every two weeks, so the client can correct course while the damage is still small. If only two weeks of work needs redoing, you simply change direction in the next two weeks.

5.3.3 The Comparison in One View

Both models run the same underlying activities — build, test, review, release — but at wildly different timescales. Waterfall does everything over six months or more; agile compresses the loop to two weeks. That two-week cycle is the heartbeat of everything that follows in this session.

When to pick which: if the product can be revised frequently and the market moves fast, agile — the default for software; if the artifact is physically frozen, waterfall remains the honest choice.

Real-world & domain. The two-week release rhythm is the industry standard behind continuous delivery: the same cadence that lets a client correct course is what lets a deployment team ship small, low-risk releases constantly. Lean manufacturing's value-stream thinking underpins this — small batch sizes and fast feedback are exactly what waterfall's six-month batch lacks.

5.4 The Scrum Team and the Sprint

Agile is delivered through a process called Scrum, and Scrum is run by a small team following a fixed cycle called a sprint.

5.4.1 Roles in a Scrum Team

A Scrum team has a product owner (PO) — the person who is effectively the client's representative inside your team, providing the requirements. Then there is the Scrum Master, who handles the entire management side: helping the team, connecting tester with developer, developer with tester, and both with the product owner. The Scrum Master is responsible for the smoothness of the whole Scrum process. Below them sit the developers, the testers, and sometimes UX designers. That is the minimal shape of a Scrum team.

5.4.2 Optimal Team Size: Ten People

The optimal Scrum team is about ten people: one Scrum Master, one product owner, two or three developers, one or two testers, and one or two UX developers. This number matters. If the team grows past ten people, you do not keep adding members to the same team — you create another Scrum team. A team above ten becomes a management nightmare: coordination cost grows, and the Scrum Master can no longer keep the process smooth. So the rule is: ten people is the ceiling, and beyond it you split.

5.4.3 Why Two-Week Sprints

Scrum is a two-week process. That is the optimum, though a sprint can run anywhere from one week to four weeks. Why exactly two weeks? Because two weeks is the shortest time in which a developer can produce a minimal viable piece of code — a small working product. With one week the code may be written but not yet operational or properly testable. With three weeks you overshoot: the first feature is finished and the developer is already half-way into a second feature, so nothing ships complete. Two weeks lets the team produce at least one minimal, running, testable product. Two weeks is also the origin of feature driven development (FDD): every sprint is built around one feature.

Real-world & domain. The ten/two shape is what makes agile work at scale: when organizations grow past one team, they split (or "scale") into multiple ten-person Scrum teams rather than fattening a single one — the same logic the lecture shows in Section 5.10.9 with multiple teams sharing one board. The two-week cadence is also what deployment teams plan against: a release every two weeks is a small, low-risk release, which is the core pattern of continuous delivery.

5.5 Agile Vocabulary: Epic, Story, Task, Subtask

Agile has four level-sized terms you must keep straight, because every board in Jira is organized around them: epic, story, task, and subtask.

5.5.1 Epic: Every Feature Is an Epic

In the agile model, every feature is called an epic. If you want to build a login feature, you create an epic called "Login." The epic contains everything that feature needs: a username area, a password area, a submit button, a cancel button, the behavior when submit is clicked, the behavior when cancel is clicked, and the backend logic. All of that is one epic. A project has multiple epics: Login is one feature, the main menu is one feature, the settings page is one feature. In a banking application the accounts page and the account list page are each separate features. The test for whether something is a feature: can it run independently? Login can run without depending on the main menu, and the main menu without depending on settings — so each is its own feature.

5.5.2 Story, Task, and Subtask

Below the epic come three smaller levels. A story (also called an issue) is a new functionality item — one piece of a feature. Within the Login epic, the stories might be the login screen, the submit logic, the API call. A task is a sub-part of a story: when a tester finds a bug, the bug is created as a task on the story, labeled "bug." A subtask is the finest grain — developer-created slices of a task. The hierarchy is always epic → story → task → subtask.

5.5.3 Definition of Ready

Before a story is allowed into a sprint, it must satisfy the definition of ready (DOR). That means the requirement is completely clear, there is no dependency on any other team, the UX screen is ready, the test cases are ready, the unit-testing cases are ready — everything a developer needs is in hand. If you start a story that is definition-ready, you can finish it within the two-week sprint. DOR is the gate that turns a vague idea into a buildable story.

Real-world & domain. This exact ladder is what Jira boards are built on — in Jira the issue types are Epic, Story, Task, and Subtask by default, which is why the vocabulary transfers to every company using the tool. The independence test for epics also drives architecture: independently deployable features map to independently deployable microservices (Section 5.2.3), which is how the agile board and the deployment architecture stay aligned.

5.6 The Scrum Flow: Board States, Ceremonies, and Workflow Rules

5.6.1 The Board and Its States

The Scrum process is visualized on a Kanban board — the board where every story's state is tracked as a column. The journey of a story across the board: backlog → pointing → ready for planning → in development (in progress) → ready for testing → testing complete → ready for demo → demo complete → ready for release → release complete → done. The demo itself mixes three agile terminologies deliberately: Kanban provides the board, Scrum provides the two-week process, and FDD (feature driven development) means the whole sprint is built around one feature. Two other agile flavors exist but are not used in this project: XP (extreme programming), where two or three developers sit together and code, and the lean process, which is based on quality.

5.6.2 Ceremony: Backlog Grooming

A ceremony is just a meeting — in agile, all meetings are called ceremonies, and every two-week sprint has four or five of them. The first is backlog grooming. The backlog holds the stories the product owner has created for future development; the owner of the backlog is always the PO. The problem: the product owner understands the business process but not the technical side, so the stories they write are business-level only — "I want a log-in screen" — with no detail. During grooming the entire Scrum team sits in one meeting and goes through every story in the backlog: does it have test cases, does it have the UX screen, does it have all the necessary information? Based on the team's comments, the PO updates each story until it is fully ready — everyone now knows exactly what development and testing must deliver.

5.6.3 Ceremony: Sprint Planning

Once stories are groomed and pointed, the planning ceremony officially starts the sprint. A sprint normally runs from Wednesday morning to Tuesday night — ten working days. Teams choose Wednesday-to-Tuesday on purpose: if the sprint starts on Monday, people come in late after the weekend and the sprint loses its first day. After planning, the PO tells everyone to start picking stories. Nobody is allocated work — team members pick their own stories. Once chosen, the story moves to in progress.

5.6.4 Development, Testing, and Demo

In development, the developer writes the code, then unit-tests it themselves. When the code passes, it goes for a code review; the reviewer checks it, and when everything is fine the story moves to the testing bucket. The tester gets notified automatically when a story is pushed. If the tester finds a bug, they create a new task on the story labeled "bug" — they do not push the story back — and the story cannot advance until the developer fixes that task. After the fix the tester re-tests, marks testing complete, and the story moves to demo. In the demo ceremony the PO verifies the application with real-time UAT (user acceptance testing): they play with everything, check the UI, the fonts, the functionality. If the PO is satisfied the story moves to the release bucket; if not, it reverts — a bug goes back as a new bug task, and a functionality change goes back as a change request (CR) to the developer, who reworks, re-pushes to testing, and re-demos. The release bucket holds a single viable version of the code that can be pushed to production, or handed to the real-time testers to work on.

5.6.5 Workflow Rules: What Can Move Where

The board is not free-form — it is configured with rules about allowed transitions. A story in the backlog can only move to pointing. From pointing it can go to planning. From planning it goes to in progress, and from in progress it cannot come back — moving to in progress is a commitment. From in progress the only forward move is to testing, but testing can come back to in progress if a bug is found. You cannot jump to demo without completing testing properly. From demo a story can revert to testing (or back to development), or move to release. From release it cannot come back to demo — it can only move to done. And once done, the code is ready for production. These arrows are configured in the tool so the process enforces itself.

5.6.6 Roles over a Story's Lifecycle

Each state has an owner. First the PO creates the story and owns it through grooming and pointing. Then the developer owns it through development, the tester through testing, the PO again at demo, and finally the DevOps engineer: they take the story at release, push the code to production, and move it to done. That hand-off sequence — PO, developer, tester, PO, DevOps engineer — is the exact path of every story you will see on every project.

Real-world & domain. These board states and arrows are exactly what Jira's workflow configuration encodes (Section 5.10): the tool does not merely display the process, it enforces it, so a card literally cannot skip testing or re-enter demo from release. That enforcement is why a DevOps engineer can trust that a story in the release bucket has genuinely passed every gate.

5.7 Story Pointing and the Fibonacci Scale

5.7.1 The Fibonacci Scale

After grooming comes pointing (estimation): the team gives every story a value reflecting how much effort it will take or how complex it is. Optimal estimation is based on the Fibonacci series. Fibonacci is built so that each number is the sum of the two before it: the first number plus the second gives the third. Formally:

$$F_n=F_{n-1}+F_{n-2}$$

with $F_1=1$ and $F_2=2$. The series technically starts at 0, but since a zero-point story is useless, the scale used here starts at 1: 1, 2, 3, 5, 8, 13. So the sequence grows as the previous number plus the current number — $1+2=3$, $2+3=5$, $3+5=8$, $5+8=13$.

5.7.2 Why 5 Is Optimal and 13 Is the Ceiling

The maximum number used in Scrum is 13 points. Even 13 is meant to be rare, and 8 should be avoided too. The optimum is 5. The breakdown rule: if a story comes out to 13, you split it into two stories of 8 and 5; if you still have an 8-point story, you split it into 5 and 3:

$$13=8+5,8=5+3$$

So in practice stories are kept at 1, 2, 3, or 5 points; 8 happens occasionally; 13 only when there is literally no way to break the story further. Beyond 13 you never go, because the next Fibonacci number is $13+8=21$, and 21 points cannot possibly be completed in ten working days. The arithmetic is deliberate: a two-week sprint has ten working days, so a developer's stories should sum to roughly ten points. To keep it intuitive, the professor suggests taking one point as about one day — but hold that thought, because Section 5.7.4 corrects this simplification.

5.7.3 Planning Poker

Pointing is done through a game called planning poker. Each team member has their own screen. The PO broadcasts a story to the whole team, and everyone privately enters the point value they think it deserves — nobody sees anyone else's number. When everyone has entered, the results are revealed. If everyone gave the same points, the story gets that value. If there is a mismatch, the PO asks each outlier to justify their low or high estimate; if the team accepts the justification, that value is used, otherwise the story takes the average of the numbers given. The justification ritual is the point of the game: low and high estimators argue from different angles, and the discussion surfaces details the story was missing.

5.7.4 Points Measure Complexity, Not Days

A common trap: treating story points as days. A five-point story can be finished in one day, and a one-point story can take four days — points have nothing to do with calendar days. Points encode complexity, estimated by gut feeling: when you read a story you know whether it feels easy, hard, or medium. The day-based interpretation was only a teaching scaffold; real agile teams estimate by complexity so that a team's throughput (Section 5.8) becomes comparable across members of different speed.

A precise note on the arithmetic: strictly speaking, a 4-plus-6 pair does sum to 10 — the professor's example means the pattern is fragile, not impossible: 4s and 6s offer only that one exact fill of the ten-day box (4 + 6), while Fibonacci values offer many exact fills — 8 + 2, 5 + 5, 5 + 3 + 2, 3 + 3 + 2 + 2. Day-based estimates also inherit whatever days feel like — a 4-day estimate from a junior and a 4-day estimate from a senior are different amounts of actual work — which is exactly why points measure complexity instead (Section 5.7.4). The professor's deeper point stands: with 4s and 6s the sprint fills cleanly only by luck, and with shirt sizes everything collapses into three buckets.

5.7.5 Estimating the First Story

There is a classic procedure for the very first story of a project, when the team has no prior reference points. The team picks one story — the first story — and each member judges it individually: is it simple, medium, or complex? A junior developer will call it harder; a senior will call it easy. The rule: take the judgment of the least experienced developer, and whatever feels "medium" to them becomes the anchor — medium is five points. Every later story is then estimated relative to that anchor: simpler means 3, more complex means 8. This is the classic, correct way of estimating; many teams today shortcut to day-based estimates, but the classic way is the one to learn, as the exchange below makes clear.

Real-world & domain. The Fibonacci scale and planning poker are used by Scrum teams in nearly every software organization — Jira's point field and velocity reports are built on exactly these numbers. The same "relative sizing over absolute precision" idea appears in release planning everywhere: teams promise in velocity units (Section 5.8), not days, precisely so that promises stay comparable sprint after sprint.

5.8 Velocity, Capacity, and Spillover

5.8.1 How Velocity Is Computed

Velocity is the team's speed — how many story points the team completes per sprint. In the first sprint the team works conservatively, because they do not yet know their own capacity. Two developers might take only 10 story points. If they finish those by the first week, they pull 10 more, and by sprint end they have completed 20 points: the team's velocity is 20. Next sprint they commit to the same 20. If they again finish early and complete 22 or 23, the velocity updates. The third sprint's velocity is the average of the first two:

$$v_3=\frac{v_1+v_2}{2}=\frac{20+23}{2}=21.5$$

If the third sprint also completes 23, the new velocity becomes the average over all three:

$$\frac{20+23+23}{3}=22$$

So velocity is a rolling average of completed points. It climbs as the team learns, then plateaus: eventually the team reaches the maximum it can complete in ten days, and beyond that point any further commitment produces a spillover. Velocity is the tool that lets you plan: at 23 points per sprint you can promise exactly 23 points, never more.

5.8.2 The Team's Ceiling and Spillover

A spillover is a story the team failed to complete in the current sprint; it rolls into the next sprint. A spilled story carries no points into the new sprint — it is not part of the sprint plan, it is simply carried debt, and it has to be completed anyway. Spillover hurts the current team's velocity because one team member stays blocked on the old story while everyone else moves on. So the default rule is: no spillovers. The fix is to commit only to your optimum velocity — the amount you know the team can deliver.

5.8.3 Spillover Points in the Next Sprint

Q: Suppose a sprint ended and a story was not finished or not tested. How do the story points count in the next sprint — the full story, or a negotiated part of it? A: The full story points carry over, and the velocity adjusts downward. Say the team planned for 30.5 points of velocity, but two points of work were not completed. The effective velocity drops to 29.5, and the next sprint picks up only 29.5 — not the originally planned 30.5. The velocity calculation (last sprint plus current sprint divided by two) already absorbs the shortfall, so the team plans to the reduced number and does not over-commit again.

5.8.4 Planned and Unplanned Leaves

Q: Vacation planning — if developers have planned or unplanned leave during a sprint, does the velocity hold? The product owner is focused on commitments, not the team's leave. A: The product owner is part of the team and is very much bothered about the team. For planned leaves, the PO asks everyone about their leave plans before every two sprints — monthly — and increases or decreases the team's velocity accordingly. For example, four people can complete 20 points; if one is away the velocity drops to 15 and the PO will not assign beyond that. For unplanned leaves, like sudden sickness, the remaining members pitch in and collectively close the story; if it falls out of the sprint, the team accepts that. None of this hits the overall project delivery, because delivery happens every two weeks regardless — you are always shipping something. What gets impacted is features: instead of five features in two weeks, you deliver three or four. The next sprint the velocity returns to normal, and a single bad week is negligible in a two- or three-year project.

Real-world & domain. Velocity is the number release planners actually promise on: at 23 points per sprint, the roadmap (Section 5.10.3) forecasts how many sprints an epic will take. Tools like Jira compute velocity and burndown automatically from completed points, which is why the "points measure complexity" discipline from Section 5.7.4 matters — if points meant days, the average would be meaningless across a team of mixed experience.

5.9 The Burndown Chart

5.9.1 What the Chart Shows

The burndown chart is the sprint's health dashboard. It plots the difference between when the team took stories and when it completed them — remaining story points against time. Each day, ideally, one point of work should burn off. The chart is the number-one early-warning device for sprint trouble: if it says nine points are still to go, or shows 33% of the sprint in progress and 67% not started, the sprint is behind and nobody is pulling work.

5.9.2 The Ideal Shape

The ideal burndown falls smoothly and steadily from start to end:

$$100\%\to 80\%\to 60\%\to 40\%\to 20\%\to 10\%\to 0\%$$

At the start of the sprint the remaining work is at 100%; after two days it should be at about 80, then 60, 40, 20, 10, and finally 0 on the last day. A good chart looks like a gentle staircase down, not a series of flat ledges.

5.9.3 What a Zigzag Does to the Team

The bad pattern is the zigzag: five days of no completions, then a sudden flood of finished stories, then more silence, then another flood. A flat-then-flood chart is not a cosmetic problem — it is a resource problem. If nobody delivers for five days, the testers sit idle waiting; from day six onward every developer hands stories over at once, the tester cannot keep up, the PO cannot finish demos, and the whole team is overloaded at the end of the sprint. The completion stream must instead be gradual and sequential: the first developer completes, the tester starts on their story while a second developer is still working, and so on, so every role has continuous work instead of a pile-up.

5.9.4 Pacing Rules and the Deployment Payoff

Pacing has an explicit rule: if one developer takes a five-point story, the next developer should take only two or three points, so testers get breathing room between stories. This benefits the deployment engineers too — a steady burndown tells them exactly what is coming next, so they can prepare the release in advance. A zigzag chart, by contrast, means deployment gets hit by a wave of finished work with no warning. The burndown chart is not just a developer's tool; it is the shared heartbeat of every downstream role.

Real-world & domain. Jira renders burndown charts automatically from completed stories, and delivery teams watch them daily in the stand-up meeting — the ten-minute daily check that this chart exists to feed. For release engineering, the same steady-cadence idea shows up as continuous delivery: small, even batches of completed work are what make every-two-week deployments low-risk.

5.10 Jira and the Atlassian Suite in Practice

5.10.1 Jira, Confluence, Crucible

The tool driving this whole board is Jira, from the company Atlassian. Atlassian offers three interrelated modules. Jira handles the stories and the tracking — the Kanban boards, sprints, and workflows you have seen in Sections 5.6 through 5.9. Confluence is the documentation tool. Crucible is for code review and inspection. They are designed to work together: story tracking, documentation, and review each get a dedicated home, and they plug into the same project.

5.10.2 Story Fields and Due Dates

Every story carries fields that matter to the process. A story sitting in the backlog typically has no story points (it has not been estimated yet), a priority such as "medium" (meaning it is not the most urgent item in the queue), no due date and no start date (it has not been taken up), and no assignee. The reporter is whoever created it. Once a story is taken into a sprint, the team fixes a timeline — a due date set from the story's complexity. Jira color-codes the timeline against today's date: if the due date is today or has passed, the date turns red, telling the assignee the story must reach the done state today. A story with a due date three days away shows normally. You see the story numbers on the board too, all children of the same epic — the epic called "Flutter app" groups every one of its stories together.

5.10.3 The Roadmap

Above the sprint level sits the roadmap: the overall plan for the whole application, running several months — for this project, roughly a single quarter. The roadmap shows the running sprint, the next sprint planned for two weeks after it, and the backlog waiting beyond. On the roadmap every epic is a bar with its child stories, color-coded by status: how many are in progress, how many done, how many still in backlog. A green checkmark over the done portion tells you that work is complete and you do not need to revisit it.

5.10.4 Sprint Management on the Board

On the sprint board itself you can create a sprint, edit it, add issues to it, complete it when everything is done, and start the next one. The sprint shows its remaining days (for example, ten days remaining). When you complete a sprint and start a new one, Jira asks for a duration — and the guidance is to use the default two-week sprint, not a custom duration. The sprint's insights section shows the point totals: so many points not started, so many in progress, summing to the sprint's committed total (a 15-point sprint in the demo: ten points not started plus five in progress).

5.10.5 Connecting Code to Stories: Branch Naming

This is one of the most important habits in the whole DevOps process: each and every story gets its own branch, and the branch is named after the story. When you check out the code and start work, you create your own branch:

git checkout -b <username>/<story-id>

If the story is DS-11, the branch is <username>/DS-11. Run git branch and it shows you which branch you are on; git status shows your changes. Because the branch name carries the story number, everything you commit is automatically tagged to that story. Once Jira is connected to GitHub, the story page shows a code block listing the branch — the reviewer can open the story, click the branch, and see exactly what difference the developer made, right inside Jira, with no other tool. When the reviewer sees that everything is fine, they mark review complete, and the board automatically moves the story to testing. The naming convention is the glue between the agile board and the version-control system.

git checkout -b <username>/<story-id>

5.10.6 Documentation and Communication

Agile teams are notoriously light on documentation, and this is a real drawback: with two-week development cycles it becomes hard to maintain documents, so you cannot go back and verify what was decided. The compensating strength is direct communication — the team meets the PO daily, and there are many channels: Slack, Teams, Communicator, and nowadays WhatsApp as well. When you do want durable documentation, Confluence is the Atlassian tool for it.

5.10.7 Q&A: Virtual Labs and Tool Access

Q: You demoed several tools. Will we get access to virtual labs where we can try the integration ourselves? A: Yes, that should be available — I will check and update you. In the meantime, note that Jenkins and Git are local applications; only Jira lives in the cloud. You can install Jenkins and Git on your own machine today and test the whole integration locally.

5.10.8 Q&A: Pull Requests and Merging

Q: When I raise a pull request, how does my branch actually merge into the main code? A: There are two ways. The developer can do it themselves: push to the branch, then use git rebase to fold your local branch onto the master branch, followed by a merge. But normally there is a reviewer in between — a team lead or a senior person who has been in the project or technology for a long time. The reviewer reviews your code and, in Git itself, marks the review complete; Git then merges automatically for you, no further commands needed. When several developers are pushing at the same time you can get merge conflicts, and the dedicated Git session covers how to resolve those.

5.10.9 Q&A: Multiple Scrum Teams on One Board

Q: If we use Kanban instead of Scrum, or run multiple Scrum teams in parallel — how does the board look in that case? A: You can have several projects running in parallel, each with its own board — this setup literally shows five projects running side by side, one Scrum, one Kanban, and others. You can also create multiple epics inside one project and they run in parallel. For multiple teams working on one application, a single board still works: the board is split by labels. Stories carry labels like "front end" and "back end"; each label implies a different Scrum happening inside the same project — a different Scrum Master and a different PO, with two sprints running in parallel on the same board.

5.10.10 Q&A: The Dedicated Git Class

Q: What are the important Git commands for this session? A: The next tutorial session is dedicated entirely to Git — a full class on Git alone. Everything will be shown there, command by command.

Real-world & domain. Jira is the most widely used agile tracker in industry, and the branch-naming convention is the standard glue between Jira and GitHub — the same mechanism (story-key-in-branch-name) that lets Jira automatically link commits, PRs, and deployments to stories. The "reviewer completes review → board moves story" automation is a standard Jira–GitHub integration pattern, and it is exactly the bridge the deployment architecture in Section 5.13 formalizes.

5.11 The Live Walkthrough: The Banner Removal Story

To make the theory real, the session follows one actual story through the entire pipeline. This is the worked example of the whole lecture: every concept from Sections 5.5 through 5.10, executed on one real story.

5.11.1 The Story

The story is "banner removal." Its description: check out the code from GitHub, remove the debug banner, and commit the changes. The story has five story points, a medium priority, and a due date of today — which is why its timeline shows red on the board. The bug itself is visible when the application runs on the Android emulator: a debug banner strip at the top of the screen. That banner is a bug because you must never ship a debug banner in a production release.

5.11.2 The Fix and the Commit

The developer makes the small code change that removes the banner, saves the file, and runs the application again — the banner is gone, so the change works. What a developer normally does at this point: verify the fix, then commit the change and push it to Git. In the demo, the push could not complete because the local machine had no GitHub connection yet, but the commit succeeded on the master branch. The commit is the point where the developer's work becomes the repository's work.

5.11.3 The Story Moves Through the Board

Back on the storyboard, the story was in progress. The developer moves it to ready for testing; the tester verifies it and moves it to demo; the PO accepts the demo and moves it to release. The story sits in the release bucket, ready for production. Then the DevOps engineer takes over: they push the build to production and move the story to done. The whole lifecycle is the role chain from Section 5.6.6 — PO, developer, tester, PO, DevOps engineer — executed live.

5.11.4 What Jenkins Does Next

The moment the code is committed, the automation starts: the Jenkins build runs automatically and pushes the resulting APK to the Play Store. That step is the bridge between the agile board and the deployment world — the story reaches done only after the build pipeline has actually shipped the artifact. The DevOps engineer returns to the board only after that automation has completed.

Real-world & domain. This exact walkthrough is the standard "first story" of every agile project: a small, well-understood fix that exercises the entire pipeline without any new functionality. The red due-date + automatic Jenkins trigger + done-only-after-ship rule is how real teams keep the board honest — a card never reaches done because someone typed it; it reaches done because the pipeline really shipped it.

5.12 Multi-Platform Builds: One DevOps Process

5.12.1 Four Platforms, Four Artifacts

The same Flutter project builds four applications: an Android app, an iOS app, a macOS app, and a web app. Each platform produces its own executable artifact: the Android APK, the iOS IPA, the macOS DMG, and the web build served by a browser — plus, in general, the Windows .exe. The demo machine could not build Windows or Linux versions, but Flutter supports them. All four applications give the same output; only the packaging differs.

5.12.2 The Build Folder

Each artifact lands in the project's build folder. For Android the path is build/app/outputs/ and the APK lives there; the iOS and macOS artifacts are created in their own output directories in the same build folder. Everything is produced automatically by the build step — you never hand-assemble an APK.

5.12.3 One Process for All

Why show all four? Because the lesson is that the DevOps process is common to all platforms. Whether you ship a system application, a web application, or a mobile application on Android or iOS, the pipeline is identical. You do not create a different deployment process for each target — one process handles every artifact, which is exactly the design goal of the Flutter example.

Real-world & domain. Cross-platform frameworks exist precisely so that teams maintain one codebase and one pipeline instead of four siloed release trains. In production, the artifact naming is universal: APK for Android, IPA for iOS, DMG/EXE for desktop, and a static bundle for web — and every one of them is produced by the same CI job, which is what keeps multi-platform releases cheap.

5.13 The Deployment Architecture

5.13.1 The Developer Side

The deployment architecture starts with the developer's integrated development environment (IDE). For Android the IDE is Android Studio; for iOS it is Xcode; for JavaScript applications it is Visual Studio Code — and even Notepad works in a pinch. Development can be online or offline, local or in the cloud. The developer takes feedback from the PO, picks up user stories, and writes code for them.

5.13.2 The Pipeline: Web Server, Repository, Build Server, Cloud

When the code is complete, the developer pushes it. The push travels through a web server that handles security and authentication; only with correct authentication does the code reach the Git repository, which stores the code. From the repository the build server — Jenkins — pulls automatically. The DevOps engineers set up the Jenkins part: they create the build jobs, the monitoring services, the scheduled services, and integrate everything, so that once the code arrives, the pipeline runs on its own. Jenkins builds the code, producing the executable packages — APK, IPA, WAR, DMG, PKG, EXE. The executables are stored, then moved to the cloud tier, because the destination stores live in the cloud: the Android Play Store, the iOS App Store, the Windows Store, and websites. End users download the artifact from there.

5.13.3 The Three-Tier View and the DevOps Engineer's Job

Read this as a three-tier architecture. Tier one, the client tier, is where development happens. Tier two is the data and code tier: the Git repository and the stored code. Tier three is the cloud tier holding the executables. The developers work in tier one; the DevOps engineer works on the automation in tier two — Jenkins jobs, monitoring, scheduling — which is the part you will work on regularly. After the build, the testers test once more, the executables are confirmed ready, and the pipeline pushes them to the respective stores.

5.13.4 The Error Path Reverses

If something fails — if the application has an error in production — the process reverses: the error flows back to development, and the whole cycle repeats. The reverse path is not an edge case; it is the designed feedback loop of the architecture.

Real-world & domain. This architecture is the shape of real CI/CD: a web server (like GitHub's) authenticates pushes, a CI server (Jenkins, CircleCI — Section 5.1.5) builds every commit, and the artifacts land in platform stores or package registries where end users download them. The "error flows back" loop is what production monitoring (Section 5.1.6) feeds — an alert in Prometheus or New Relic becomes a bug story, which restarts the whole cycle.

5.14 The Build Pipeline: Build, Test, Lint

5.14.1 The Five Steps of the Build Script

The build is driven by a shell script in the project's build-process folder — this is the shell scripting from Section 5.1.3 in action. The script runs five steps in order:

1. Build. Compile the application — flutter build apk --debug, where Gradle (the Android build manager) performs the "assemble debug" build and runs many internal processes.
2. Run the unit test cases. Verify the compiled code works.
3. Run code cleanup and lint. Check code quality with the lint tools from Section 5.1.8.
4. Generate the APK. Produce the deliverable artifact once everything is clean.
5. Install and open. Install the APK on the connected device and open the application for further testing.

After these steps, the DevOps configuration also sets up a monkey process — a randomized UI exercise that pokes at the installed app — which runs in the background. The demo executes all three background activities at once: build, test, lint — and the outputs appear as the pipeline runs.

5.14.2 Failure Escalation Paths

Each failure type has its own escalation route:

• If the build fails, the developer is notified — they broke compilation and must fix it.
• If a test fails, both the developer and the tester are notified, because both own the quality of the test and the code.
• If lint fails, the developer and the reviewer are both updated, because a lint failure is a code-compatibility problem — the code compiles but still has issues, so the reviewer (who will release the code) and the developer work together.

These three paths map exactly onto the tool categories: build problems belong to the developer, test problems to developer plus tester, and quality problems to developer plus reviewer.

5.14.3 The Pipeline in Motion

Running the script live, you see what Jenkins does internally: first the Gradle build (many processes visible), then the test run against a release build, then the lint check, then the install and launch on the emulator. The build step prints build successful, the tests pass, the lint is clean — and that sequence, visible step by step at a command prompt, is exactly what the Jenkins job will do automatically in Section 5.15.

Real-world & domain. This five-step shape is the standard commit stage of a delivery pipeline: compile → automated unit tests → static analysis/lint → package → (optionally) deploy to a test environment. Real CI servers (Jenkins, CircleCI) run exactly this sequence on every push, and the monkey process is the same idea as Android's UI fuzzers and randomized monkey testing used to shake out crashes before release.

5.15 Jenkins: Job Configuration and Build Triggers

5.15.1 Configuring a Job

Jenkins jobs are configured with three essential pieces: where the code lives (the repository URL and branch — the same code you saw in Git), the credentials, and the build step. The build step is the heart of the job: the execute shell step, which runs the same shell script you executed manually in Section 5.14. Whatever you showed at the command prompt, Jenkins now runs for you.

5.15.2 Build Logs and Failure Emails

Every build produces a log — you open the build and read exactly what happened, step by step. If the build fails, Jenkins sends an email to the DevOps engineer; you can also add the developer's mail IDs, comma-separated, so the person who broke the code gets notified too. If the build succeeds, no email is sent. The log plus the failure mail is the whole observability story for builds.

5.15.3 Trigger: Poll SCM

The next question is when the build should run. Should it run every five minutes? The first option is poll SCM: Jenkins checks the GitHub server on a schedule, and if new code has arrived, it builds. The schedule is a cron expression — the five-star cron * * * * * means every minute. Polling keeps hitting the repository to ask "anything new? anything new?" which works but is chatty.

5.15.4 Trigger: GitHub Hook

The second, better option is the GitHub hook (webhook): instead of Jenkins polling, GitHub pushes a notification the moment new code arrives — "I got a new build, please start building." This is the optimized solution because nothing polls and nothing waits; the build starts exactly when the code changes.

5.15.5 Trigger: Build Periodically

The third option fits very large projects where developers push every five minutes. Building for every single push wastes resources, so you batch: wait an hour or two and build everything at once. The build periodically option takes a cron expression: H * * * * runs once every hour, H/2 every half hour, H/4 every 15 minutes, and a value like 4 runs every four hours. The Jenkins help text itself advises not to run every four hours when hourly is enough. The demo showed the next run time advancing: built at 8:23, next run 9:23. This is the batch process that matches the automation pattern from Section 5.1.3.

5.15.6 Trigger: Build After Other Projects

The fourth trigger solves a classic failure mode with backends and frontends. If the backend is not ready and you release the frontend, users download the app from the Play Store, start using it, and it crashes — because the backend it talks to does not exist. That is a public embarrassment. The rule: build the backend first; only once it is stable and running, build the frontend. In Jenkins this is the build after other projects option: you name the upstream project (by project ID), and Jenkins watches it — if that project's last build was stable, this project builds; otherwise it waits.

5.15.7 Q&A: Windows Applications and Batch

Q: What about Windows applications — building software into an installer? Is that handled by Jenkins too? A: Yes, with one small change. The build step here is execute shell, which is for Linux, Unix, and macOS. For Windows you use execute Windows batch command instead: create a .bat file with the full path to it, and Jenkins builds the Windows artifact. Jenkins itself runs on Windows too — you can install your own Jenkins on a Windows machine. There is a build step for every platform, and beyond the built-in ones, the Jenkins plugin manager (under the settings icon) lets you download plugins for almost anything; if a build step does not exist, a plugin provides it.

5.15.8 Q&A: Mapping Builds to Work Items

Q: When a build runs, can we identify which work item it was for? A: Yes — this is exactly why the branch naming convention exists. The branch is named after the story number, for example DS-10. When a build runs on that branch, you know it belongs to story DS-10. If the build fails, you know which developer's branch caused it. When several developers' branches are being built at once and one fails, you remove that branch, rebuild, and the other four branches run fine — isolating the culprit is a five-minute operation.

5.15.9 Q&A: Installation and Configuration Depth

Q: Some of us come from infrastructure backgrounds. Will the sessions cover installing and configuring tools like Jenkins, Git, Puppet, and Chef from scratch? A: We will not have time to show installation from scratch — that alone can eat five to ten minutes per tool, and the sessions run about two hours. We will show configuration, not installation. Installation itself is very easy; you can pick it up from tutorials. If time permits, I will configure Puppet and Chef live for you, though they are not in the main tutorial list.

Real-world & domain. Jenkins is the on-premises CI/CD workhorse (Section 5.1.5), and the four triggers map onto real pipeline design choices: webhooks are how GitHub, GitLab, and Bitbucket all notify CI today; H-spread cron is how large Jenkins farms avoid synchronized build stampedes; and "build after other projects" is the same dependency ordering that pipeline tools express as upstream/downstream stages. The branch-named build traceability is why the branch naming habit from Section 5.10.5 is considered one of the most important DevOps conventions.

5.16 Cron Jobs and Scheduling

5.16.1 The Five Fields

A cron job is a Linux background task that runs on a schedule. The schedule is written as a five-field expression — each field tells cron when to fire:

$$\text{(minute, hour, day of month, month, day of week)}$$

A typical expression is written with the fields separated by stars: * * * * *, which means every minute — every value is a wildcard. The five stars are the default pattern you start from. Jenkins uses the same five-field notation for its scheduling options, which is why the "poll SCM every minute" setting was the same five-star expression in Section 5.15.3.

5.16.2 Ranges and Overflow

Each field has a maximum value, and the numbering is zero-based. The minute field holds at most 59: if you need something at minute 60, that is not a minute anymore — it spills into the hour field. The hour field holds at most 23: minute 0 of hour 24 is midnight of the next day, so it spills into the day field. Understanding the overflow is how you translate a plain-language schedule into the correct fields: the hour comes first in the written expression, then the minute, which is a classic source of confusion.

5.16.3 Wildcards and Special Names

Besides numbers, cron supports wildcards. In Jenkins, H in a field means the job runs once within that unit — H in the minute position of an hourly job means "once this hour, at some minute." Some cron implementations also accept named macros such as @yearly (once a year), @hourly, and @reboot (run whenever the machine starts). These macros are non-standard: some cron versions accept them, others throw an error. In the demo, Jenkins accepted @yearly without complaint.

5.16.4 Common Patterns

Putting the fields together, here are the standard patterns, described in words and written in cron notation:

• Run at 12 o'clock noon each day: 0 12 * * * — minute 0, hour 12.
• Run at 10:15 each day: 15 10 * * * — minute 15, hour 10. Note the order: hour comes first in speech but the minute is the first field.
• Run at exactly 14 minutes past 2 o'clock: 14 2 * * *.
• Run every 5 minutes, but only during the 2 o'clock hour: */5 2 * * * — the / notation means "every 5th value of the field."

These are the calculations a DevOps engineer does every day — and only DevOps engineers configure them, since other team members do not get access to the scheduling layer.

These are the calculations a DevOps engineer does every day — and only DevOps engineers configure them, since other team members do not get access to the scheduling layer.

5.16.5 crontab in Action

On Linux, macOS, and any Unix system the cron configuration lives in the user's crontab — the "cron table." You edit it with crontab -e (the -e flag means edit). A cron job points at a command or script; in the demo the crontab calls the build shell script from Section 5.14 and redirects its output into a log file, build.log.txt. After saving, cron reports "installing new crontab," and the job starts running. There is no log file at first — it appears only after the job has run once, which is how you verify a cron job fired. This is how DevOps creates background threads that run constantly: hourly builds, health checks, cleanup jobs.

5.16.6 Windows Has Its Own Scheduler

Cron is a Unix-family feature; Windows does not have it. Windows uses its own scheduled-task tool — the name of which slipped the professor's mind mid-sentence, but it is the standard Windows Task Scheduler. The concept is the same: define what to run and when. Every platform and every tool has some batch-process mechanism — Jenkins has its cron-based schedules, Unix has cron, Windows has Task Scheduler — so the pattern to learn is the five-field schedule, not a specific program.

Real-world & domain. The five-field schedule is the shared language of every scheduler a DevOps engineer touches: Linux crontab, Jenkins build periodically, cloud platform cron (e.g., AWS CloudWatch Events and scheduled functions), and backup/health-check automation. "Only DevOps engineers configure them" is literal in most organizations — the scheduling layer is a controlled surface, which is why the skill is part of the DevOps engineer's daily calculations.

5.17 Unit Testing, Feature-Driven Development, and TDD

The final concept block is about how tests drive development, and it answers a doubt raised about feature driven development (FDD): how does FDD differ from plain unit testing and from test driven development (TDD)?

5.17.1 Unit Testing

Unit testing is the simplest, smallest level of testing. It is done by the developer, for individual components: the submit button, the cancel button, the username text field, the password text field — each component tested in isolation. Unit tests are a broken-down fragment of feature-driven development: they prove the parts work, one at a time, but they do not prove the feature works end to end.

5.17.2 Feature-Driven Development

FDD works at the feature level. For one feature there will be a success scenario and a failure scenario — both are created as test cases. The practice: write the test case first, then write only enough code to satisfy that specific test case, then add the next test case, then code for it — test case by test case, scenario by scenario. Critically, FDD does not include security testing at all: security is a common concern that applies to every feature, not one feature, so it is written once in the TDD layer instead of being repeated per feature.

5.17.3 Test-Driven Development

TDD is everything written in one shot: for the whole application you write the success cases, the failure cases, the regression cases, the performance testing, the security testing, and the load testing — all together. So the layering is: unit tests cover single components, FDD covers one feature's success and failure paths, and TDD carries the full suite — regression, performance, security, load — in one go. Security is a separate feature of its own in the TDD layer.

5.17.4 The Login Feature as an Example

Concretely, take the login feature. The front end builds the login screen with username, password, submit, and cancel — including the cancel functionality and the login button logic that calls an API. In parallel, the back end builds the security service: whatever mechanism the organization uses — Okta, LDAP, or Active Directory (AD) — the backend implements it and, within the ten working days of the sprint, hands the developer the API to consume. The completed feature is demoable: success username plus success password logs in; success username plus failure password throws an error; both wrong, it fails. The PO tests all four combinations and concludes: this feature is complete.

5.17.5 Who Writes What

Q: You said TDD includes security, performance, regression, and load testing. Do the developers write all of that? A: No — the tester writes it. In the agile process it is teamwork: the same story is updated by developer, tester, PO, and the UX person. The tester writes the user test cases and creates the main task with the four or five test cases inside it. The developer then opens the story, creates their own subtask, writes their own TDD test cases there, sets the due date, and works on it. Only the developer works on the subtask; the tester's and PO's work stays at the task level.

5.17.6 SRS Mapping: Epics, Features, Tasks, Subtasks

Q: In our organization we follow SRS mapping: multiple epics broken into features, features into user stories, stories into tasks. How do FDD, TDD, and BDD map onto that? A: Your case is a rarer setup. By default in agile, the feature is the epic — teams normally do not create something called a "feature." The default hierarchy is epic → story → task → subtask, with four issue types. But Jira always allows you to create custom issue types: you can create an issue type named "feature" and use it below the epic. If you do, FDD applies to that feature. Normally, though, teams apply FDD at the task level: every task will have its own feature tests. The practice: the tester creates the test suite — the task description lists "success case 1," "success case 2," "failure case 1," and so on, each written as a bold heading with bullet points like "the app should have a login button; upon pressing login, it should verify the user's credentials." The developer then breaks the task into subtasks, one per test case — success case 1 becomes subtask one, case 2 subtask two — and closes all subtasks to close the main task. Ownership is strict: the epic is created by the PO, the task by the PO and tester, and the subtask by the developer. There is no standard or style guide for the subtask content — it is developer-private, never seen by the PO or tester, which is exactly why no standards exist for it.

Real-world & domain. The three-layer split is how real teams run: developers own unit and subtask-level tests, QA owns the regression/performance/security/load suites, and CI runs all of them on every commit (Section 5.14's step 2). BDD (behavior-driven development) is the sibling practice mentioned in the Q&A — like FDD's scenario language, it phrases tests as "given/when/then" behavior, but the default agile hierarchy the professor teaches remains epic → story → task → subtask with the feature as the epic.

Exam Guidance Summary

The session ends with assessment guidance worth collecting in one place:

• Quiz timing and scope. The quiz is the same assessment already posted on the portal — it is not a different quiz — and it is specific to the portion of the course discussed in this session and the theory that accompanies it. The quiz window was extended so that everyone could take it; it stays open for roughly two days from this session. Take it now, while the concepts are fresh — that is exactly why the quiz is offered at the end of the session: an hour or two later you would need to search for the answers.
• What the quiz covers. The questions come from a mixture of both: this session's content and the theory portion. Anything that was discussed here and in the theory sessions is fair game.
• FDD terminology. A specific doubt about feature-driven development was raised and answered: every epic is a feature, FDD works per feature with success and failure scenarios written before the code, and security testing belongs to the TDD layer, not FDD. Expect the distinction between unit testing, FDD, and TDD to matter.
• The Git session. The next tutorial session is dedicated entirely to Git: branches, rebase, merge, pull requests, and merge-conflict resolution. Important Git commands were explicitly deferred to that class.
• Deferred integrations. The end-to-end flow — story creation, branch creation, push to Git, automatic Jenkins build, Play Store deployment — will be shown fully once the GitHub and Jira integrations are connected in a later session. The Jenkins configuration, cron scheduling, and branch naming conventions covered here are the pieces of that flow.
• Study the tool map. The tool landscape in Section 5.1 — which tool does configuration management, which does deployment, which does monitoring, which does linting — is the foundation every practical session builds on.

Key Industry Applications

• Real-world: Prometheus and Grafana form a widely used open-source monitoring stack in production; Google Analytics and Firebase cover web and mobile analytics; New Relic is a commercial APM product. All are integrated into real DevOps pipelines.
• Real-world: GitHub, GitLab, and Bitbucket are the repository hosts used in practice; TeamCity and SVN remain in use in older enterprises.
• Real-world: Jenkins and CircleCI are the CI/CD workhorses — Jenkins on-premises, CircleCI as a cloud CI service.
• Real-world: The Android, iOS, and Windows stores are the production destinations for mobile and desktop artifacts; the push-notification gateways in the web tier are how apps like WhatsApp deliver alerts.
• Real-world: JUnit (Java), Karma, Jasmine, Cucumber, and Mockito (JavaScript and hybrid), and Selenium and Appium (mobile and system apps) are the standard test tooling split; Android Lint, JS Lint, ES Lint, Swift Lint, Apache JMeter, and Micro Focus LoadRunner are the standard quality-and-load tooling split.
• Real-world: Okta, LDAP, and Active Directory are the identity mechanisms a login backend integrates with; Office 365, Teams, and social-media connectors (Facebook) appear as real microservices inside the service tier.
• Real-world: Slack, Teams, and WhatsApp are the communication channels that replace documentation in agile teams, with Confluence used when durable documents are needed.
• Real-world: Puppet and Chef remain common configuration-management tools in infrastructure teams, alongside the Git family.