Scrum development – basic and common problems

Scrum is widely used by many companies, organizations but to really know its true principles and practical methods is very hard. People always say that they are using Scrum for development but no one can really say that how many percentages of Scrum principles they are applying in reality.

Let work through the Scrum foundation and some common problems to find out that percentage number!

1. Definition

First of all, we start by going through the definition: “Scrum is a management and control process that cuts through complexity to focus on building products that meet business needs” ( and “Scrum is an Agile framework for completing complex projects” (

2. How does it work?

scrum framework to use for a Sprint

Product owner creates a prioritized wish list called a product backlog.
During sprint planning, the team pulls a small chunk from the top of that wish list, a sprint backlog, and decides how to implement those pieces.
The team has a certain amount of time — a sprint (usually two to four weeks) — to complete its work, but it meets each day to assess its progress (daily Scrum).
Along the way, the ScrumMaster keeps the team focused on its goal.
At the end of the sprint, the work should be potentially shippable: ready to hand to a customer, put on a store shelf, or show to a stakeholder.
The sprint ends with a sprint review and retrospective.
As the next sprint begins, the team chooses another chunk of the product backlog and begins working again.

3. Some know-hows

Scrum Team

The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional.

Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity.

Product Backlog

Product Backlog The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.

A Product Backlog is never complete. The earliest development of it only lays out the initially known and best-understood requirements. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. As long as a product exists, its Product Backlog also exists.

The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate and value.

The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.

The Scrum Product Backlog shall not contain the detailed requirement information. Ideally the final requirements are defined together with the customer during the sprint. Breakdown and distribution of these requirements is the responsibility of the Scrum Team.

Sprint Backlog

The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal

The Product Owner

The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:

  • Clearly expressing Product Backlog items;
  • Ordering the items in the Product Backlog to best achieve goals and missions;
  • Optimizing the value of the work the Development Team performs;
  • Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
  • Ensuring the Development Team understands items in the Product Backlog to the level needed.

The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.

The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.

For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says.

3. Common problems

How big is a Scrum Team?

Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint.

Having more than nine members requires too much coordination.Large Development Teams generate too much complexity for an empirical process to manage

What are the differences between user stories and tasks?

A user story is typically functionality that will be visible to end users. Developing it will usually  involve a programmer or tester, perhaps a user interface designer or analyst, perhaps a database designer, or others.

A task, on the other hand, is typically something like code this, design that, create test data for such-and-such, automate that, and so on. These tend to be things done by one person.

So, perhaps the better distinction is that stories contain multiple types of work (e.g., programming, testing, database design, user interface design, analysis, etc.) while tasks are restricted to a single type of work.

How detailed should tasks within a user story be?

The Scrum Guide doesn’t suggest that tasks are required, and it doesn’t recommend task size or a specific estimation process. It does suggest that refinement of product backlog with details and estimates is an ongoing process and “usually consumes no more than 10 percent of the capacity of the development team.” So, while the Guide doesn’t suggest how much detail should go into user stories or tasks, it does advise time-boxing the time spent in planning and refinement.

Getting the right level of detail for the user stories and associated tasks during a sprint planning meeting can be a challenge. The team needs to have enough detail to implement the story, but they also need to be efficient in their sprint planning meeting. Creating tasks that take about a day or less is the most common practice.

What should we do in Sprint Planning?

In Sprint Meeting, the Product Owner presents each item and explains how he/she sees it working from a functional perspective. The whole team discusses the item in detail. The whole team asks questions about the feature in order to establish what it should do and how it should work. You can use whatever form of writing requirements you want to. But the important principle in Scrum, and in any agile development methodology, is that you write requirements feature by feature, just before they are developed.

What really happens in Sprint Planning?

The first thing you must do (in your first Sprint Planning meeting) is decide on your Sprint duration.

The second part of the Sprint Planning Workshop is focused on breaking the requirements into tasks and estimating the hours required to complete them. Make sure the meeting is attended by all team members. Include all roles. Business Analysts if you have them. Testers if you have them. ALL Developers on the Scrum team for the product. The Product Owner and any customer, user or business representatives need not attend this part (part 2) of the Sprint Planning workshop, as it’s likely to be more technical in nature and is more about the team working out how the selected backlog items will be delivered. However, they should be welcome to attend if they wish, which may help their understanding of what’s involved to deliver the features, and may help if any further clarification is required as the tasks are discussed and estimated.

What do tasks look like in Scrum?

Tasks may include the traditional steps in a development lifecycle (although limited to the feature in question, not the entire product). For instance: Design, Development, Unit Testing, System Testing, UAT (User Acceptance Testing), Documentation, etc.

Keep tasks small. Estimate all tasks in hours. Estimate each task as a team. Ideally task estimates should be no more than 1 day. If an estimate is much larger than this, the requirements should be broken down further so the tasks are smaller. Although this can be difficult, it will get easier with practice.

Always include some additional scope in your Sprint Backlog, over and above what you think can be achieved. This is important in order to have something ready if the team delivers early, as the Sprint should ideally remain a fixed length.

Clearly identify these items as Stretch Tasks. The Product Owner should never expect Stretch Tasks to be reached. No-one should ever be beaten up if Stretch Tasks are never reached. And if you do manage to complete any Stretch Tasks, this should be cause for celebration!



Kỹ năng viết User Story với nguyên lý INVEST

Mở  đầu

User Story là một khái niệm căn bản khi làm việc theo phương pháp Agile. Mỗi User Story là một yêu cầu bất kì đối với sản phẩm nhằm hướng tới mục tiêu mang lại giá trị tốt hơn cho khách hàng. Thông thường các user story được tách riêng lẻ trong bảng Backlog (bảng lưu trữ các yêu cầu sản phẩm) nên còn được gọi là Product Backlog Item (PBI)

user story

Trong bài viết này chúng ta sẽ đi sâu vào cách viết 1 PBI tốt bằng phương pháp INVEST


Trước hết, mỗi PBI cần là một yêu cầu độc lập, không phụ thuộc vào bất kì PBI khác trong tính năng.

Các PBI có thể liên kết với nhau theo hướng tham khảo hoặc dùng như là một điều kiện tiên quyết, tính năng bổ trợ nhưng bản thân yêu cầu của từng PBI là hoàn toàn riêng biệt.

Đây là yêu cầu đầu tiên vì nếu không có sự tách biệt thì sẽ dẫn tới sự chồng chéo, dư thừa. Tổn hao công sức của Product Owner.

First thing you need is to ensure the PBI is independent, not replicate others.


Một PBI cần có tính linh hoạt. Cho tới trước khi nó được giao vào một tiến trình phát triển sản phẩm thì một PBI có thể được chỉnh sửa, viết lại, bổ sung bất kì lúc nào.

Tại sao lại cần linh hoạt? Vì thực tế nhu cầu của thị trường, của khách hàng luôn luôn thay đổi. Phương pháp Agile nhấn mạnh tính quan trọng của việc luôn thích ứng với thực tế, không ngại thay đổi. Đó là lý do của nguyên tắc này.

Real business always changes, don’t freeze your requirements.


Hãy chắc rằng một PBI mang lại giá trị nào đó cho sản phẩm, người dùng. Không cần phải giải thích thì ai cũng biết rằng khi chúng ta làm một điều gì đó thì tất nhiên phải hướng tới việc tạo ra giá trị. Trong phát triển sản phẩm cũng vậy, bạn cần nhìn lại xem điều mình dự định làm có mang lại giá trị gì trong ngắn hạn, trung hạn, dài hạn không?

Do things valuable and you will absoluately be happy with your work.


Có thể định lượng được. Hãy chắc rằng bạn hiểu cơ bản cần bao lâu để làm xong một yêu cầu. Luôn có 3 yếu tố xác định thành công của một dự án – sản phẩm đó là THỜI GIAN – CHẤT LƯỢNG – GIÁ CẢ. Bạn cần cân nhắc kĩ yếu tố đầu tiên – Thời Gian trong mối tương gian với các yếu tố khác để quyết định thứ tự ưu tiên của các PBIs.

Time passes and cannot be back.


Đủ nhỏ và đơn giản. Ngay từ đầu 1 PBI chỉ là một yêu cầu đơn lẻ nhằm giúp Product Owner có thể dễ dàng định lượng độ ưu tiên của các tính năng. Chính vì vậy hãy đảm bảo 1 PBI không quá lớn để có thể hiểu và nắm bắt nhanh.

Simplicity is simply perfect.


Có thể kiểm tra, đánh giá được thành quả. Một yêu cầu có tốt đến mấy trong ý tưởng nhưng không có cách đánh giá thì không có gì đảm bảo kết quả làm ra đúng với mong đợi. Vì vậy hãy đảm bảo mô tả của bạn có đầy đủ thông tin để đánh giá chính xác mong muốn của yêu cầu.

Measuring is always a hard thing to do.


công việc tìm hiểu nghiệp vụ

Happy investigating!