Normally in Agile development, people don’t mention about Business Analyst role. So what will be the true story behind the scene?
Business analysts play an important role: Traditionally, they act as the link between the business units and IT, help to discover the user needs and the solution to address them, and specify requirements. But in Scrum, there is no business analyst role. (Roman Pichler)
What will BA do in a Scrum team?
Option 1: product owner
This is a natural move. The individual needs to own the product on behalf of the company instead of analyse and get features approval from specific clients. For that significant change, the individual might need to learn new skills to adapt new role.
Option 2: team member
The role of business analyst as a team member will mostly to address and help other members groom product backlog. Since this responsibility is for the whole team, business analyst inside a Scrum team usually covers additional tasks as well like writing technical documents, coordinate with testers.
The role of a Business Analyst in an Agile project is not well-defined just as there is no defined role for a Project Manager on an Agile project. On small, simple Agile projects there may not be a need for either of these two roles but that is frequently not the case on large, complex enterprise-level projects.
The role of a BA is often neglected – it is assumed that the Product Owner plays that role but it can be difficult for a Product Owner to perform that role without some assistance on very large complex projects
(chuckc3)
Option 3: proxy product owner
Dealing half-heartedly with the role of business analysts in Scrum is a common mistake: Business analysts neither play the product owner role nor are they team members. Instead, they end up as proxy product owners, a go-between the real decision maker and the development team, as shown blow.
Using a proxy product owner is best avoided—certainly as a permanent solution.
(Roman Pichler)
Why this model is not-recommended? Because it requires many communication to verify each single decision thus brings lots of miscommunication, misunderstanding as well as inconsistent product requirements. At the end, no one is really the Owner of Product.
The head of a business unit was asked to take on the product owner role for a new product. As he struggled to fill the role effectively, the business analyst stood in as a proxy. While the analyst did all the detailed grooming work, the business unit head decided about the product features and when which functionally was released. Unfortunately, this resulted in miscommunication, a long-winded decision-making process, and poor morale. (Roman Pichler)
Conclusion
There is no fixed direction, solution for a traditional business analyst to follow in Scrum world. But I think from the above suggestions, insights, we’re all more clear about the basic concepts.
Scrum is not a plug-and-play environment that will guarantee that product development will succeed. If improperly managed, the product development will not adequately scale to the customer’s requirements, which will increase costs, impact return on investment, and lead to instability. (Sriramasundararajan Rajagopalan)
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” (scrum.org) and “Scrum is an Agile framework for completing complex projects” (scrumalliance.org)
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 neededto accomplish the workwithout 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 tothe 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!
Làm việc với con người chưa bao giờ là một công việc dễ dàng. Thế nhưng “cái khó ló cái khôn”, luôn luôn có những bài học vô giá mà người đi trước để lại cho các thế hệ sau bí quyết để giải quyết các vấn đề khó khăn. Đối với vấn đề giao việc, mô hình SMART là một trong những mô hình nổi tiếng và hiệu quả nhất mà một nhà quản lý nào cũng cần phải nắm vững.
SMART là một từ tiếng anh, mỗi chữ cái là một nguyên lý được viết tắt. Sau đây chúng ta sẽ lần lượt đi từng nguyên lý một.
S – Specific
Bất kì điều gì giao ra cần phải rõ ràng. Sẽ chẳng có ý nghĩa gì nếu người khác làm một điều không đúng với ý muốn của bạn. Tất cả mọi thứ sẽ trở thành công cốc. Lãng phí tài nguyên, lãng phí cơ hội, lỡ hẹn với khách hàng, đối tác, …
Bạn cần rất rõ ràng, từng chi tiết, đặc biệt là các vấn đề dễ nhầm lẫn. Hãy đặt ra các câu hỏi quan trọng như nguyên tắc 5W (what, where, why, who và which)
M – Measurable
Phải định lượng được. Bất kì yêu cầu gì đưa ra cần phải có khả năng cân đong, đo đếm để đánh giá tình trạng của nó. Nếu không có cách đánh giá thì công việc không bao giờ có thể hoàn thành. Việc có khả năng đánh giá tình trạng công việc còn giúp tránh tình trạng
Đây là lúc các câu hỏi về How cần được đưa ra để biết được kế hoạch thực hiện công việc, cách đáng giá từng công đoạn, …
A – Attainable / Agreed / Achievable
Mục tiêu đề ra là khả thi, có thể đạt được. Một lẽ dĩ nhiên là bạn không thể cứ mơ tưởng được đi trên cung trăng rồi giao cho nhân viên của mình tìm cách chế tạo một chiếc du thuyền có khả năng bay lên mặt trăng trong vài ngày.
Công việc chỉ có thể hoàn thành và hoàn thành đúng hạn nếu các kì vọng vào nó là hiện thực, được người làm công việc đó xác nhận là có thể làm được.
R – Relevant / Realistic / Resourced / Relevant
Không có điều gì là hoàn hảo nhưng sự phù hợp nhất là thứ mà chúng ta luôn tìm kiếm. Nếu chỉ cần xong việc và không quan tâm tới tương lai, bạn có thể bỏ qua nguyên tắc này. Nếu ngược lại, bạn cần lùi lại một bước để nhìn thấy viễn cảnh xa hơn cho tổ chức, công ty khi giao một công việc.
Công việc này có phục vụ một mục tiêu chung của tổ chức, có tạo ra giá trị mà bạn đang hướng tới. Người thực hiện công việc có phải là người tốt nhất để làm công việc này? Liệu họ có đủ kiến thức và kinh nghiệm cũng như việc này có giúp họ phát triển bản thân thêm?
Chúng ta cần suy ngẫm nhiều hơn bên ngoài bản thân công việc đang cần giao.
T – Time Dependent / Time-bound
Cuối cùng mà nói, bạn cần một mốc thời gian cụ thể để nghiệm thu công việc. Việc có một cột mốc giúp người thực hiện thấy được mức độ ưu tiên, tập trung vào những vấn đề quan trọng cần làm để hoàn thành đúng kế hoạch.
Hạn mức thời gian này cần có được sự tán thành và xác thực của người thực hiện như là một thành tố của công việc được giao.
Chúc các bạn thành công trên vai trò một người quản lý.
Với hai luồng văn khác biệt của Gào và Minh Nhật, “Chúng ta rồi sẽ ổn thôi” mang đến cho người đọc những góc nhìn rất người, rất thật và rất khác lạ của những con người mang trong mình máu nghệ sĩ. Đọc tản văn này, ta như được chiêm nghiệm lại những từng trải trong đời tác giả.
Có những thứ tham khảo thì vẫn chỉ có giá trị tham khảo, bởi … “Có những thứ hoàn toàn phụ thuộc vào cảm nhận. Bạn không ở đó, khó lòng đánh giá nó, chỉ bằng mắt nhìn.”
Ai cũng ngại khó khăn, nhưng … “Nếu bạn nề hà chuyện cùng người mình yêu thương vượt qua khó khăn trong cuộc sống, có nghĩa là bạn không hề yêu họ”
“Con người ghét chờ đợi, … Nhưng chẳng phải chúng ta vẫn luôn chờ đợi một điều gì đó sao?” Và rằng … “Sự thật là chờ đợi một điều kỳ diệu chính là thứ chúng ta vẫn thường làm trong cuộc đời này.”
“Những quyết định lớn có thể thay đổi cuộc đời người ta đôi khi chỉ đến từ những điều thật đơn giản mà thôi” nhưng dù gì hãy làm một việc là “Hãy luôn yêu người ở bên cạnh mình”.
Bởi chỉ có tâm hồn và cảm xúc là vĩnh cửu, còn “Những gì bạn sở hữu phần lớn sẽ quay lại sở hữu con người bạn, tâm hồn bạn…”
Tình cờ đọc được một bài rất hay về cuộc sống nên tạm dịch:
……
……
Thứ chúng ta chưa córồi sẽ có, điều chúng ta đang córồi sẽ mất.
Hãy làm việc để tiến tới mục tiêu và mơ ước của bạn, nhưng nên nhớ rằng có thể một lúc nào đó, khi nhìn lại, bạn sẽ phải mơ về nhiều điều mà hiện tại bạn vốn dĩ đang có. Đó có thể là sức khoẻ, là tuổi trẻ hay thậm thí là một tình yêu đã lạc lối của bạn. Chúng ta sẽ mất đi nhiều thứ trên đường đời chúng ta đi.
Hầu hết chúng ta đều đã là những người giàu có. Chúng ta có nhiều hơn những gì chúng ta thật sự cần, chúng ta giàu có hơn con người trong đa số các nền văn minh nhân loại từ xưa tới nay, và chúng ta cũng có giàu có hơn rất nhiều nơi trong thế giới hiện tại. Chúng ta giàu có về vật chất, tuổi thọ, sức khoẻ, sự tự do, những đứa con khoẻ mạnh và rất nhiều thứ mà chúng ta đều nghĩ là tất nhiên có sẵn trong cuộc sống này.
Đừng để việc thiếu trân trọng những gì bạn đang có, việc thiếu nhận thức về hiện tại khiến cho bạn quá chú ý vào tương lai , vào những gì người khác có mà bạn không có.
Hãy nhớ rằng, đừng đểviệc bị ám ảnh về những gì bạn chưa cóhuỷ hoạinhững gì bạn đang có.
Ngẫm: Độ dài của cuộc sống là một khái niệm tương đối, với một số người nó dài như vô tận, đối với một số người nó lại quá ngắn ngủi để trải nghiệm mọi thứ trên khắp thế gian này. Vì thế, hãy cố gắng sống mỗi ngày với sự trân trọng và hài lòng để không bao giờ chúng ta phải hối tiếc vì một ngày vô nghĩa trôi qua.
Blog có khá nhiều bài viết về kĩ thuật rồi nên hôm nay mình sẽ viết một bài dịch, tổng hợp về chủ đề đời sống giúp mọi người thư giãn và tham khảo. Mong mọi người cùng góp ý và chia sẻ. 🙂
Dẫn nhập
Áp lực trong công việc luôn tồn tại từ trước tới nay nhưng nếu để áp lực tồn tại quá lớn, chúng ta sẽ bị rơi vào tình trạng stress. Tình trạng này đã được nghiên cứu rất nhiều, còn được gọi bằng khái niệm “kiệt sức tâm lý”, điều gây ra nhiều tác hại nguy hiểm tới sức khoẻ con người.
Với những công việc tay chân thuần tuý, có lẽ chúng ta khó có thể làm gì khác để cải thiện tình hình khi áp lực công việc lớn. Tuy nhiên, với những công việc thiên về trí não, nếu biết giải quyết đúng cách chúng ta có thể vượt qua áp lực và đạt được năng suất làm việc tốt trong tình trạng áp lực đè nặng. Sau đây là 2 công thức, phương pháp mình xin trích dẫn:
Công thức START (Bắt đầu)
bảo vệ mình
Dân gian ta vẫn có câu “phòng hơn chống“, đây là phương thức tiếp cận phòng ngừa, giảm thiểu nguy cơ tạo ra áp lực quá lớn cho bản thân. Áp dụng phương pháp này sẽ giúp chúng ta giảm thiểu rủi ro khiến chúng ta mất bình tĩnh và quẫn trí.
S – Stand Up
Ngay thẳng: nêu rõ quan điểm của bản thân và kế hoạch cá nhân. Đừng khiến mình bị người khác lôi đi vòng vòng một cách vô hướng, hãy biết nói không khi cần thiết.
T – Trust
Tin tưởng: tin tưởng vào chính bản thân mình và mọi người. Không có sự tin tưởng chúng ta sẽ không thể hoàn thành việc gì.
A – Action
Hành động: cố gắng hết sứcđể thực hiện chiến lược và kế hoạch đã đề ra. Giảm thiếu tối đa các phiền nhiễu như những cuộc họp không cần thiết, những cuộc tán gẫu điện thoại quá lâu, lướt web quá nhiều …
R – Respond
Tương tác: hãy đảm bảo bạn có khả năng tương tác hai chiều với người quản lý, đồng nghiệp và tất cả những người liên quan. Hãy thường xuyên thông báo cho họ những thông tin cần thiết đồng thời lắng nghe những ý kiến của họ.
T – Take It Easy
Suy nghĩ tích cực: đừng quan trọng hoá bản thân hay nhiệm vụ bạn được giao. Tất cả chúng ta đều có thể được thay thế, mọi chuyện đều có thể được giải quyết. Hãy bình tĩnh và thư giãn dù tình huống gì có xảy ra.
Công thức SWITCH (Chuyển đổi)
hãy là chính mình trong bất kì tình huống nào
Phòng thì tất nhiên là tốt hơn chống nhưng đôi khi điều tồi tệ vẫn xảy ra, hãy đối mặt. Phương pháp Switch sẽ giúp cho chúng ta giữ được sự sáng suốt và bình tĩnh dù bị chìm dưới biển sâu tăm tối.
S – STOP
Dừng lại: dừng việc đuổi theo cái đuôi của chính bản thân mình như một chú mèo mới lớn. Ngồi yên. Đừng động đậy.
W – Wait
Chờ đợi: hãy đảm bảo rằng bạn có đủ thời gian và không gian yên tĩnh mà bạn cần.
I – Inhale
Hít thở: hít vào và thở ra thật sâu. Điều này làm giải toả căng thẳng trong đầu bạn, cân bằng cảm xúc và ổn định hoạt động của các giác quan khác trong cơ thể của bạn.
T – Think
Suy ngẫm: suy ngẫm về tình trạng mà bạn đang gặp phải. Hãy cố gắng tìm ra nguyên nhân cốt lõi và những mối liên hệ dẫn tới trình trạng hiện nay. Điều quan trọng là: hãy dành đủ thời gian để suy ngẫm, nó thường lâu hơn bạn hình dung.
C – Calculate
Định hướng: tính toán và lên kế hoạch tiếp theo. Dù là với cá nhân hay tập thể, hãy đề ra mục tiêu rõ ràng, phân bổ chúng ra thành các công việc nhỏ cho hàng tháng, hàng tuần, hàng ngày. Các công việc đó nên có các tính chất sau: cụ thể (specific), đánh giá được (measurable), làm được (actionable), thực tế (realistic), và có hạn mức thời gian (time-bound); tức là chúng có tính thông minh (SMART).
H – Head and Proceed
Hành động: một khi đã xác định được mục tiêu và kế hoạch, điều cần làm lúc này là tiến lên và thực hiện chúng thôi.
