We present real-life example cases from Scrum teams and projects that can enrich your real-world knowledge of the Scrum framework, Scrum Master, Product Owner, and Development Team topics.
BVOP™ Senior Scrum Master
BVOP is a modern Agile organization that created the Senior Scrum Master certification program, which follows its new Agile methodology.
Create an account on the BVOP.org platform to receive a promotional discount code. Certification exams are entirely online.
The cost of the certification exam is $ 55 if you have a promo code. So hurry up and register on BVOP.org
The director of your organization wants to launch the development of three new products and informs you that a team of 10 is required for the largest product in volume. There are 15 specialists available for all new products.
Such a distribution of people would be illogical and unprofitable. Even if Scrum allowed the minimum number of people to be 3, it would mean that someone would fulfill more than one role and be an absolute expert in their dev sphere.
The three new products should be categorized by priority and type/number/complexity of the expected development tasks for each. If this allows the use of a minimum number of people without disrupting the workflow and being able to overcome difficulties (true cross-functionality of the team), it will be possible to concentrate more human resources towards the so-called larger in volume product. In any other situation, you may need to hire new staff.
The Director is of the opinion that the lower priority products do not need to have a Product Owner role.
Each product has its own development life cycle based on tasks, sprints, increments, etc. on the logic of execution. Whether it is low priority or not, the product must be seen as development. It must have a clear goal, a plan based on its expected business value. Ie, someone should have a vision of the product in question and how it should be developed. There’s no way this can be solely entrusted to a Scrum Master or Development team who may not be able to categorize value or prioritize tasks.
The director insists that, as he has many years of experience in managing people, he wants to be the CEO of the largest team, to set tasks on a daily basis, and to request reports from each member of the team.
In Scrum, this would be incompatible with the already outlined work framework. The dev team defines their tasks on a daily basis and how to accomplish them. And the role of the Scrum master is to check the progress of their implementation – daily scrum. Excessive admission of additional people and roles will only aggravate the workflow and lead to confusion.
The director tells you that a project manager has been appointed for each product by the client, who, in case of urgent requests, will assign each team member a priority for the day.
In the presence of a Product Owner, the appointment of the Project Manager (or Product Manager) would be superfluous. The roles are similar, albeit with a different focus (mentioned in the previous module). Assigning additional tasks will only cause confusion and stress for the team. The Development team ultimately sets the tasks for the day on its own and has its own estimate for the time needed. Their tasks are entirely related to the current sprint, and any additional one can change/delay the performance of the others.
One of the senior programmers of the teams tells everyone that since the team is big and he has a lot of experience, he will officially accept the role of Team Lead. She adds that she will choose technology, offer a way of working for each member of the team and monitor the progress of tasks.
The Development team structure does not (in most cases) allow Team Lead to be present. The team takes overall responsibility and selects its tasks on a daily basis, no further intervention is needed. Of course, the presence of staff with extensive experience is welcome, but their knowledge and skills could be channeled in a different direction to the team, such as backlog analysis, training of new staff, etc.
A newly recruited employee from your organization tells you that since he is a beginner and still in trial, he prefers not to interfere in team decisions and does not want to take responsibility for product work.
Team solutions help to overcome any potential difficulties. It is quite understandable that there is an internal concern about inexperience and immaturity overwork topics. The team assumes overall responsibility for the work (set in the appropriate sprint) on the product, not individually. A shadowing, mentoring, training process may be considered to acquire additional skills with the help of the team as a whole or of senior/knowledgeable staff.
You understand that most of your team members have already spoken with your HR manager and have been granted permission to work outside the office.
As we already know, the team itself determines how to work and deliver on product development. If communication and product progress are not slowed down in any way by who the team is at any given time, then there should be no problem. I would encourage working in an atmosphere that should appeal to everyone, but let’s not forget that live communication (and not just for daily scrum) is much more effective than any other option. A separate issue is that it is work in a professional environment and there should be an optimal division of office-out-of-office work that everyone should consider. Last but not least, it would be a good idea to coordinate with Product Owner and Scrum Master before being approved, as they are stakeholders in the Dev team’s work to achieve optimum sprint results.
A member of the Development Team is pleased to announce that, outside of office hours, he has written an extensive collection of code that he can easily add to the product, and through it can speed up much of his tasks and some of those of the rest of the team.
This is great news, but it needs to be coordinated with the whole team (including Product Owner and Scrum Master) to be able to join the next sprint. It would be good to have transparency about the work done, documenting it and measuring it as work (+ QA tested). It’s great to think of the team and the overall progress, but it has to be official. And last but not least, she can emphasize rest after the end of her working day
The development team offers you the idea that you set an estimated time for task completion, and that they focus on their work and spend their time on tasks. They shared this with the Product Owner role, and he was quite pleased.
It is the dev team that determines the time required to complete a task and the work as a whole. All this is based on experience, knowledge, practice, skills, etc. If anyone has an adequate measurability rating, then this is the Dev team. It is not appropriate for anyone else to specify this parameter.
The teams of the three parallel products being developed by your organization have decided to reorganize. Their desire is to be divided into teams according to their profession and qualification.
One team will be programmers, the second will be designers, and the third will be quality control. They have suggested you as an activity coordinator.
The dev team must be cross-functional, which implies people with different knowledge and skills needed to complete the sprint in question. Breaking them into sub-teams with a specific profession and functionality makes no sense of the idea that together they solve all problems and have a team responsible for the accomplishment of the work done. I would not encourage such a restructuring.
The development team shares the opinion that User Story contains too little information and wants more details.
I would advise the Development team to list the ambiguities and address it with the Product Owner so that it can be corrected as quickly as possible and the user story is completed on time.
The Product Owner has asked one of the team members not to temporarily report problems and defects on the product, publicly in your defect recording system, but to correct them themselves.
Scrum “professes” transparency. This cannot be done in the situation mentioned above. Defects must be described and any action taken to correct them. All of this, once analyzed, brings more experience and knowledge of future identical problems and helps the team build on their skills and routine.