<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Engineering Practices :: Link You to Scrum</title><link>https://www.scrum.link/engineering-practices/index.html</link><description>Engineering Practices There is a crucial distinction between knowing something and truly understanding it. Theory alone is not enough — real comprehension comes from doing. The video “The Backwards Brain Bicycle - Smarter Every Day 133” illustrates this perfectly. Watch it on youtube or bilibili
The same principle applies here. It is strongly recommended to get your hands dirty and work through the engineering practices yourself.</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Tue, 14 Apr 2026 14:45:46 +0800</lastBuildDate><atom:link href="https://www.scrum.link/engineering-practices/index.xml" rel="self" type="application/rss+xml"/><item><title>Pair Programming</title><link>https://www.scrum.link/engineering-practices/pair-programming/index.html</link><pubDate>Tue, 14 Apr 2026 14:45:46 +0800</pubDate><guid>https://www.scrum.link/engineering-practices/pair-programming/index.html</guid><description>What is Pair Programming? Pair programming is a collaborative software development technique where two developers work together at one workstation. It’s a staple of Extreme Programming (XP) and it is a proven method for boosting code quality and accelerating knowledge sharing across a team..
The process relies on two distinct roles that rotate frequently:
The Driver: The person at the keyboard. They focus on the tactical task of writing code, managing syntax, and handling the immediate implementation. The Navigator: The “observer” who keeps an eye on the big picture. They review the code in real-time, anticipate potential bugs, consider edge cases, and ensure the solution aligns with the broader system architecture. Why Pair Programming? While pair programming isn’t a mandatory requirement for Agile teams, it has become a gold standard for high-performing engineering cultures. Here’s why teams invest the extra “brainpower” into a single task:</description></item><item><title>User Story</title><link>https://www.scrum.link/engineering-practices/user-story/index.html</link><pubDate>Tue, 24 Mar 2026 14:45:46 +0800</pubDate><guid>https://www.scrum.link/engineering-practices/user-story/index.html</guid><description>Why User Story? Managing a Product Backlog is not easy. A Product Owner must keep it informational, understandable, and clear. The User Story is one effective approach to achieve this, and it is widely adopted in Agile development.
The Structure of User Story User Stories are usually written in a pre-defined structure:
As a [role] I want [action/item] so that [purpose/benefit] For example
As an Online Shopper, I want to save items to a "Wishlist", So that I can easily find and buy them later without searching again. A Good User Stroy with ‘INVEST’ The INVEST acronym helps teams evaluate the quality of a User Story:</description></item></channel></rss>