Gökrem Tekir graduated from Anadolu University in 1997 as an Industrial Engineer.
He worked as a project engineer in different companies in the production and service sector. He earned the PMP Certificate in 2004.
After receiving the PMP Certificate, he continued his career as a Project Management Trainer and Consultant.
Among the trainings he gave, there are topics such as Fundamentals of Project Management, Agile Project Management, Scrum Approach, Project Planning and Follow-up with Microsoft Project, PMP Exam Preparation.
The consultancy services offered by Gökrem Tekir are the Establishment and Integration of Project Management Offices, Microsoft Project Server and Sharepoint Integration, Development of Enterprise-Specific Project Management Methods, Planning and Reporting of Projects Between Buyer and Sellers, Creation and Follow-up of Project Plans of Institutions, Projects of Employees. It is listed as Adapting to Management Methods.
Gökrem Tekir is the author of the first Turkish-language Project Management book in 2006. In 2017, a much more comprehensive work titled "Our Life is the Project - Project Manager's Handbook" was also published.
Gökrem Tekir continues to share information on social networks such as Youtube, Linkedin, Twitter and Instagram in order to spread his knowledge on project management.
Gökrem Tekir continues his training and consultancy services within the body of Istanbul Kurumsal Gelisim Ltd. company.
Product Backlog and Work Breakdown Structure (WBS) are two important planning tools used in project management. Although they are similar in some ways, they differ in their scope, purpose, and level of detail.
Product Backlog
A Product Backlog is a prioritized list of features or requirements that a team plans to deliver in a project. It is a dynamic document that is updated continuously throughout the project lifecycle. The Product Backlog is owned by the Product Owner, who is responsible for prioritizing the items based on their value to the customer.
The Product Backlog helps the team to understand and plan what they need to deliver. It is a high-level view of the project that provides a big picture of what the product will look like. The items in the Product Backlog are not broken down into smaller tasks.
Work Breakdown Structure (WBS)
A Work Breakdown Structure (WBS) is a hierarchical decomposition of the project deliverables into smaller, manageable components. The WBS breaks down the project into smaller, more manageable pieces that can be estimated and scheduled. Each component of the WBS is called a Work Package.
The WBS is a detailed view of the project and is used to plan and manage the project execution. It is owned by the Project Manager, who is responsible for ensuring that the project is completed on time, within budget, and meets the quality standards. The WBS includes all the tasks required to complete the project and is used to track progress and identify potential issues.
Differences
The main differences between Product Backlog and Work Breakdown Structure are:
Scope: Product Backlog focuses on the high-level view of the project, while WBS focuses on the detailed view of the project.
Purpose: Product Backlog is used to prioritize the features or requirements to be delivered, while WBS is used to plan and manage the project execution.
Level of Detail: Product Backlog does not break down the items into smaller tasks, while WBS breaks down the project into smaller, manageable components.
In conclusion, both Product Backlog and Work Breakdown Structure are important planning tools that are used in project management. While they have some similarities, they differ in their scope, purpose, and level of detail. Understanding these differences is crucial for effective project planning and execution.
Are you tired of managing projects that seem to drag on forever? Do you feel like you’re constantly putting out fires instead of making real progress? It’s time to try a new approach.
Introducing Scrum for Project Managers, the e-book that will revolutionize the way you approach project management. Our comprehensive guide will teach you everything you need to know about Scrum, an agile project management framework that has been proven to increase productivity, improve communication, and deliver results.
In this e-book, you’ll learn the basics of Scrum, including how to create and manage a product backlog, how to conduct sprint planning and review meetings, and how to effectively communicate with your team. You’ll also discover advanced techniques for improving team collaboration, managing stakeholder expectations, and delivering high-quality products on time and within budget.
Whether you’re a seasoned project manager or just starting out, Scrum for Project Managers is the must-have resource for anyone looking to improve their project management skills. And with our easy-to-read format and practical advice, you’ll be able to start implementing Scrum in your projects right away.
Chapter 1- Scrum Approach
The Agile Manifesto and the Birth of Scrum. 10
Overview of Scrum Framework 12
Scrum Artifacts 14
Organizational Goals in Scrum 16
What is the Backlog? 19
Chapter 2 – Product Backlog
Product Backlog in Scrum 23
An Example of Scrum Practice 25
User Stories 27
Refining and Estimating Product Backlog 30
Chapter 3 – Sprint Backlog
Sprint Backlog 35
Sprint Scope and Sprint Goal 37
Chapter 4 – Definition of Done
Increment and Definition of Done 42
More Details of “Definition of Done” 45
When should the DoD be Prepared? 48
Definition of Done vs. Acceptance Criteria 50
Chapter 5- Scrum Events
What are Scrum Events? 53
What is a Time Box? 55
More Details About The Sprint 57
Sprint Planning Event 59
Why is the Sprint Valuable? 61
What can be Done in the Sprint? 63
How will Things Be Done in the Sprint? 66
Who Attends the Sprint Planning Meeting? 68
Coherency of Sprint Backlog Items 70
Daily Scrum 72
Sprint Review Meeting 74
Sprint Retrospective Meeting 76
Understanding Epics 80
Special Sprints 83
Canceling a Sprint 85
Chapter 6 – The Scrum Team
Scrum Team 88
Scrum Team Size 90
Product Owner 92
What is Value 94
How is the Product Backlog Ordered? 96
The Developers 98
The Scrum Master 100
How does the Scrum Master serve to the Scrum Team 102
What is an Impediment in Scrum? 104
How does the Scrum Master serve to the Product Owner? 106
How does the Scrum Master serve to the Organization 108
Other Titles in Scrum 110
Chapter 7 – Scaling Scrum
Introduction To Scaling Scrum 115
What happens when multiple Scrum Teams work on the same Product? 117
Impact on velocity when scaling Scrum 118
Integrated Product Increments 120
The Definition of Done when multiple teams work on the same Product 122
Must the Sprints be aligned? (same length, same start/end) 124
How many Product Owners are there? 126
Feature teams vs Component teams 128
The importance of creating an integrated Increment 130
Chapter 8 – Terms and Tools Used in Scrum
The Velocity of the Scrum Team 134
Technical debt 136
Functional and non-functional requirements 138
The process of emergence in Scrum 140
Burn-down charts 142
Burn-up charts 144
The “cone of uncertainty” 146
Chapter 9 – Agile Framework and Practices
Agile Framework Overview 150
Kanban 152
Extreme Programming (XP) 155
Test-driven development (TDD) 157
Behavior-driven development (BDD) 159
DevOps 161
Chapter 10 – FAQ about Scrum
Is Documentation Mandatory in Scrum? 165
What happens with incomplete Sprint Backlog items? 167
Who creates the Definition of Done? 168
How to change scope without affecting the Sprint Goal? 170
What happens if there is no Increment and/or the Sprint Goal is not reached? 171
The difference between Product Backlog Refinement and Sprint Planning 173
What is the difference between creating an Increment and Releasing it? 175
About The Author
Gökrem Tekir graduated from Anadolu University in 1997 as an Industrial Engineer.
He worked as a project engineer in different companies in the production and service sector. He earned the PMP Certificate in 2004.
After receiving the PMP Certificate, he continued his career as a Project Management Trainer and Consultant.
Among the trainings he gave, there are topics such as Fundamentals of Project Management, Agile Project Management, Scrum Approach, Project Planning and Follow-up with Microsoft Project, PMP Exam Preparation.
The consultancy services offered by Gökrem Tekir are the Establishment and Integration of Project Management Offices, Microsoft Project Server and Sharepoint Integration, Development of Enterprise-Specific Project Management Methods, Planning and Reporting of Projects Between Buyer and Sellers, Creation and Follow-up of Project Plans of Institutions, Projects of Employees. It is listed as Adapting to Management Methods.
Gökrem Tekir is the author of the first Turkish-language Project Management book in 2006. In 2017, a much more comprehensive work titled “Our Life is the Project – Project Manager’s Handbook” was also published.
Gökrem Tekir continues to share information on social networks such as Youtube, Linkedin, Twitter and Instagram in order to spread his knowledge on project management.
Sprintlerin yapısında şu mantık esastır. Önümüzdeki 1 ay içinde ne yapacağımızı düşünmek mi daha kolaydır, yoksa bütün bir sene içinde yapılacaklarınızı düşünmek mi? Tabii ki, kısa vadeli bir plan yapıp, sonucu gördükten sonrasını tekrar planlamak çok daha kolaydır. Bu sayede, planlama için ayırdığınız çaba da daha az olacaktır.
Sprintin amacı, Scrum takımının belirli bir hedefe odaklanmasını sağlamaktır. Sprintler, küçük de olsa, bir şeyi başarmak için kullanılır. Ekibin dikkatinin dağılmasına izin vermeden ve kesinti yaşamadan proje hedefine odaklanmalarını sağlar.
Bir şirkette, aynı anda yürüyen farklı projeler olduğunu varsayın. Ekip üyeleri, gün içinde bu farklı projelere dağılmış durumdayken, ortaya çıkan herhangi bir sonuç olmayacaktır. Scrum yaklaşımında, ekip üyeleri tek bir projeye odaklanır ve en azından, küçük de olsa, bir değer üretmek için çalışırlar.
Özetle, çevik yaklaşımlar, işlere başlamaktan ziyade bitirmeye odaklanır. Sprintleri çok küçük projeler olarak görebilirsiniz. Böylece, küçük zaman aralıklarında, müşterinin geri bildirimde bulunabileceği veya doğrudan kullanabileceği sonuçlar ortaya çıkarmak mümkün olacaktır.
Sprint esnasında Scrum takımı, baştan düşünmedikleri şeyleri fark edebilir. Diğer ifadeyle, Scrum Takımı, sprint hedefinin beklediklerinden daha büyük olduğunu anlarlarsa, ürün sahibi ile müzakere ederek, kapsamı azaltabilir, fakat kaliteden asla ödün veremezler. Kapsamın azalması, yeni fark edilen içeriklerin sonraki sprintlerde yapılmak üzere, ürün birikim öğesine eklenmesi anlamına gelecektir.
Benzer bir durum, Sprint süresi için de geçerlidir. Sprint süreleri, 1 aydan uzun olmayacak şekilde belirlenmelidir. Pratik uygulamada, sprint süreleri genellikle 2 hafta olarak tercih edilir. 2 haftalık döngülerle, uygulamaya konulma potansiyeli olan çıktılara ulaşmak, proje içinde bir rutin oluşturulmasını kolaylaştıracaktır.
Eğer sprint hedefinin, beklenenden daha büyük olduğu anlaşılırsa, sprint süresi uzatılmaz. Artan kapsam içeriği, sonraki sprintlere aktarılmak üzere ürün birikim öğesi olarak kaydedilir.
Sprint süresinin 2 hafta olması zorunlu değildir. Farklı sprint süreleri, proje boyunca kullanılabilir. Scrum ekibi ve ürün sahibi arasındaki müzakereler çerçevesinde, sprint süresine karar verilebilir.
Bununla birlikte, büyük bir projede farklı Scrum takımlarının, farklı sprint süreleri kullandığını düşünün. Birbirine entegre edilmesi gereken çıktıların, farklı zamanlarda üretilmesi proje ilerlemesinde düzensizlik yaratacaktır. Buna karşılık, ekiplerin ortak bir sprint süresi üzerinde anlaşarak sprintleri yürütmeleri, ekipler arasında senkronize çalışma şekli yaratacaktır.
