Most of the company working with Agile and most of us getting confused with its types, Here you can find the most important information that you need to know.
Don't let it confuse any more! 😄
Agile
Introduction🫥
Once upon a time, there was a group of software developers who were tired of the old way of doing things. They were tired of spending months or even years on projects that were never finished, and they were tired of having to throw away their work every time the customer changed their mind.
The developer was from different development methodologies backgrounds, but this didn’t stop them from brainstorming to find a solution to software development that could lead to faster development time and was less documentation-heavy.
They wanted a solution with scope for constant feedback to avoid the cost of rework at a later stage so that all agreed on Agile and that was the porn of Agile Methodology.
So now let’s have a deeper look at agile and get a better understanding of their concept
What Exactly is Agile🤔??
Agile Software Development or the Agile Manifesto is a set of Values and principles that encourage flexibility, adaptability, communication, and working software over plans and processes.
It allows the team to work together more efficiently and effectively in developing complex projects. It consists of practices that exercise iterative and incremental techniques that are easily adopted and display great results.
⚠️ When these brilliant developers agreed they decided to put 4 core values and 12 principles for Agile, These values and principles were established to guide software development and project management practices to be more flexible, customer-focused, and responsive to change
Agile 4 values😁
Let’s begin with the agile values:
- Individuals & Interactions over Processes &Tools.
- The relationship between our team members is more important than the process used.
- Working software over comprehensive documentation.
- in the V model or waterfall life cycle, we might notice a large number of documents, by writing SRS or the user requirements, we might create sequence diagrams, UML diagrams, or any other diagrams that will help us in developing the software, but in Agile software, the comprehensive documentations are not important like a working software.
- so no matter how much is the documents about the login functionality, the importance is the login functionality is working.
- but also it doesn’t mean that we don’t have any type of document, it‘s still important to have a document it’s just the working software is more important.
- Customer collaboration over contract negotiation.
- At the beginning of any project, we create a contract, but what if the customer wants to make an adjustment in the middle of the work?? we should do whatever he says and make the adjustments, but it doesn’t mean that we have to build the project from scratch, we’ll collaborate with the customer and give him the highest quality to meet the user expectations and that will give the customer a high review.
- Responding to change over following a plan.
- if there are changes in the project we can change the plan, and we could respond to the changes.
Processes and tools, comprehensive documentation, contract negotiation, and following a plan, are all these values are important but Individuals and interactions, Working software, Customer collaboration, and Responding to change have more important values.
Agile 12 Principles😁
😅
Don’t worry🤣it’s easy to recognize just focus with me.
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- IN other words, our highest priority is to satisfy the customer using many methods like scrum and others, and also it will be done by continuous and early delivery.
- Deliver working software frequently, at intervals of between a few weeks to a few months with a preference for the shorter timescale.
- Working software is a primary measure of progress.
- Welcome changing requirements, even late in development, Agile processes harness change for the customer's competitive advantage.
- we need to collaborate with Our customer, they has many competitors in the market and they are changing strategies and plans, this is why our customer also needs to change his plans and strategies.
- Continuous attention to technical excellence and good design enhances agility
- everything should organized in a good way in order to move fast and easily.
- Agile processes promote sustainable development, Sponsors, developers, and users should be able to maintain a constant base indefinitely.
- The art of maximizing the amount of work not done is essential.
- anything that will not add value to your project don't do it.
- Anything that you are able to cancel, just cancel it, this will make our team focus on the important functionalities.
- Build projects around motivated individuals, give them the environment to support their needs, and trust them to get the job done.
- The whole team must believe in the idea of the project, and they must be motivated to and they must be motivated to get the job done, the team manages itself.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- like we said, it is better for the team to self-organize itself.
- Each team member assigns his tasks to himself and also adds estimates to them, then begins working on them.
- Stakeholders and developers must work together daily throughout the project.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
- our agile team must evaluate itself, This evaluation is very helpful in increasing something that's called the team velocity
👌 This the 12 principles that will help us to work in an Agile team efficiently and effectively.
What is Agile Testing😀?
AGILE TESTING: is a testing practice that follows the rules and principles of agile software development. Unlike the Waterfall method, Agile Testing can begin at the start of the project with continuous integration between development and testing. Agile Testing methodology is not sequential (in the sense it’s executed only after the coding phase) but continuous.
Waterfall vs. Agile
Waterfall is a linear approach to software development. In this methodology, the sequence of events is something like:
- Gather and document requirements
- Design
- Code and unit test
- Perform system testing
- Perform user acceptance testing (UAT)
- Fix any issues
- Deliver the finished product
Agile It is teamwork-based software development where continuous iteration is possible and focuses on customer satisfaction. Here both development and testing are done simultaneously.
☝ Example, I am creating content about Agile.
If this course is using Waterfall:
In this case, I need to plan the topics, allocate time for recording, gather necessary resources, and determine the team members required for video editing, slide creation, video uploading, captioning, and recording.
If this course is using Agile:
On the other hand, if I am using Agile, I will have two video editors, one technical editor for captions, and a full-time designer for slide creation. I need to decide the time frame for releasing the software or course, preferably within one month.
Next, I will identify the features that can be included in the course within one month. After developing, uploading, and publishing the course, I can gradually add more features in the following months.
So, in sequential models or waterfall, the requirements are fixed while the resources and time are estimated, In Agile, the resources and time are fixed while the requirements are estimated.
User Requirement as User story✌️
User story : is written to capture requirements from the perspectives of developers, testers, and business representatives. The user stories must address both functional and non-functional characteristics.
The important goal is to capture the requirements of the user in a good way that the whole development team can understand.
User **Requirement :** A traditional requirement focuses on functionality — what the product
should do. The remaining differences are a subtle, yet important, list of “how,” “who,” and “when.”
login functionality
📌 User Story:
“As a train passenger, I want to be informed of delays in real-time so that I can plan my journey accordingly.”
Requirement:
Display the estimated delay times of each train.
*Types of Agile Methodologies*
There are many methodologies in Agile, Scrum, Extreme Programming, and Kanban, these are considered the most famous three mythologies in Agile.
Scrum
Scrum can easily be considered to be the most popular agile framework. The term ‘scrum’ is much considered synonymous with ‘agile’ by most practitioners.
Who are the people involved in Scrum?
- The Product owner
- The product owner is accountable for maximizing the value of the product resulting from the work of the Scrum team. How this is done may vary widely across organizations, Scrum teams, and individuals.
- The Product Owner is also accountable for effective product Backlog management, which includes:
- Developing and explicitly communicating the product Goal
- Creating and clearly communicating product Backlog items.
- Ordering product backlog items and, ensuring that the product backlog is transparent, visible and understood.
- Scrum Master
- Scrum master is accountable for establishing scrum as defined in the scrum guide.
- The Scrum master helps everyone understand scrum theory and practice, both within the scrum team and the organization.
- is also accountable for the scrum team's effectiveness, they do this by enabling the scrum team to improve its practices within the scrum framework.
- he is also a true leader who helps the scrum team and the organization.
- The development team
- The development team is the team that develops and tests the software.
Every methodology has it own practices, these are the one used by Scrum team:
- Sprint:
- Scrum divides the project into iterations or “sprints” of fixed length.(usually two -to four weeks).
- Product Increment:
- Each sprint results in a potentially releasable/shippable product (called an increment)
- Product backlog:
- The product owner, manages a prioritized list of planned product items and the product backlog evolves from one sprint to another, which is called backlog refinement.
- sprint backlog:
- at the beginning of each sprint, the scrum team selects a set of highest priority items from the product backlog. Since the scrum team, not the product owner, selects the items to be realized within the sprint, the selection is referred to as the being on the pull principle rather than the push principle.
- Definition of Done:
- To make sure that there is a potentially releasable product at each sprint’s end, the Scrum team discusses and defines appropriate criteria for sprint completion. The discussion deepens on the team’s understanding of the backlog items and the product requirement.
-
Timeboxing:
- Only those tasks that the team expects to finish within the sprint are part of the sprint backlog. if the development team can’t finish a task, it’s moved back into the product backlog.
- So how do we do timeboxing? We do it using something that's called a planning poker at the beginning of the sprint. the whole team meets and decides how many points we will give the user story based on the complexity of and the amount of testing and we give it a number and this number follows the Fibonacci sequence. then applied the planning poker which is start from 1 and then we say 1+1=2 and then 1+2=3,3+2=5 and so on until 20, if it has a bigger point it turns to an Epic
-
Transparency:
- The development team reports and updates sprint status on a daily basis at a meeting called the daily scrum or start-up meeting. this makes the progress of the current sprint visible to everyone.
So now we will finish the sprint and then we will have our report
- The “Burn-down chart” shows the amount of work that has been completed in an epic or sprint, and the total work remaining. Burn-down charts are used to predict your team's likelihood of completing their work in the time available. They're also great for keeping the team aware of any scope creep that occurs.
- The “velocity chart” tracks the amount of work completed from Sprint to sprint this helps us determine the team's velocity and estimate the work our team can realistically achieve in future sprints.
At the end of each sprint, we should hold a meeting that's called a retrospective meeting.
- Retrospective meeting: is a meeting that held at the end of each iteration to discuss, what was successful, what could be improved and how to incorporate improvements in future iterations.
Extreme programming
Extreme programming is a very popular agile methodology also, but it is different than Scrum, Scrum focuses on management, It divides the project into iterations, and identifies specific roles in the project, On the other hand, extreme programming focuses on development and testing, not management.
Extreme programming :is an agile methodology that's popular with software teams since the 1990s, it doesn't focus on project management, like scrum, but it also focuses on how teams build their code.
Important definitions in Extreme programming:
- Quarterly Cycle: once a quarter the XP team organizes meetings to do planning & reflection
- Weekly Cycle: the weekly cycle practice is a one- week iteration in which the team choose stories and builds working software that’s “Done” at the end of the week.
- Slack: Any time the team creates a plan, the team adds a slack by including a small number of optional or minor items.
- add the item that we are expecting to finish during this sprint and add the slack to them, So if you finish your work during this sprint, go to the slack and finish what is listed inside it.
In order for your development team to apply extreme programming, we should have new versions that may be built several times in your day. in each day, the developer changes his code. These code changes are pushed to the continuous integration server, then they are unit tested and integration-tested, We should have increments that are delivered to customers every one or two weeks, all tests must be run for every build.
Extreme Programming :
- New versions may be built several times per day
- All tests must be run for every build and the build is only accepted if test run successfully.
- Increment are delivered to customers every 1 or 2 weeks
All of these methods are used in agile teams or not agile teams, whether it's applying extreme programming or not.
Why Extreme ??
In extreme programming, we push each development activity to the extreme of it.
- we have effective practices, those effective practices are used in sequential models, and we make them extreme programming Practices.
- The first one, for example, is code reviews, in sequential models. So we replace code reviews with pair programming. We have two persons who are reviewing the work product, At the same time.
- Testing as an activity might be performed in a manual way or exploratory way, here we have unit testing and continuous integration and regression testing, and all testing activities are automated.
- We have a design, We design the software, We design our code, then write it. Nowhere we have persistent refactoring after writing the functionality or designing the software, we always edit the design, and we always refactor it.
- simplicity as a concept in agile projects, We push simplicity to the extreme, So we have simple design, simple code and code only that is required, anything that is not important, remove it from your project.
- short iterations in agile projects, in extreme programming, One of the 12 principles is the "Planning Game", and the planning game in the customer and the development team sit together to plan what we are going to perform or develop in this iteration.
We have five values that guide development in Extreme programming:
- Communication: means that we always communicate.
- Simplicity: simple design, simple code, anything that doesn't give me value don't develop it.
- Feedback: changes happen a lot in extreme programming, at least daily, maybe two or three times per day so we should had feedback.
- Courage : if you think that your team doesn’t do the best you should have the courage to say that and the management should accept the information.
- Respect: the opinion of any team member should be respected.
12 principles of XP:
- the planning game:
- the client and the development team should work together in planning the product, the beginning of the project or at project initiation, we should have a large planning session and smaller stations at each iteration.
- small Release :
- We should have releases as frequently as possible to gain feedback, and this feedback is best achieved.
- smaller releases also allow estimates to be more certain, it easier to look a week or two ahead, rather than months so, in the extreme, keep the iterations very short.
- System Metaphor :
- A system metaphor makes it easier to explain the product to someone else; it can be an analogy to describe the product to someone who is not technical.
- Examples Desktop & Shopping cart metaphors.
- Simple Design :
- focus on the simplest design that work to satisfy the client’s need.
- Requirement change, so it would be wasteful in making elaborate design for something that will change
- Don’t over engineer the design for a future that may not come. So, in the extreme make the simplest thing that works.
- Continuous testing :
- In XP, test are prepared for a required features or functionality before it’s corresponding source code is written.
- Use test-driven Development{TDD}, in the normal unit testing we write the code and test it, in TDD we write the test and then we write the code.
- Refactoring :
- is restructuring the internal design of the code without changing its behavior.
- a large module can be decomposed into smaller more understandable pieces.
- Unnecessary code can be removed.
- If refactoring is neglected, technical technical debt is increased.
- Pair Programming :
- two developers work side-by-side at one computer to work on a single task.
- Collective code Ownership :
- No individual owns the code.
- The produced work is the team, not individual, so project success and failure resides with team, not on specific developers.
- Continuous Integration :
- developers combine their code often to catch integration issues early. this should be at least once daily, but it can be much more frequent.
- 40-hour work week :
- XP respects the developers balance of work and life.
- At crunch time, up to one week of overtime is allowed, but multiple weeks of overtime would be a sign of poor management or estimation.
- on site Customer :
- The client is situated near the development team throughout the project to clarify and answer questions.
- Coding Standards :
- All the development agree to and follow a coding standard that specifies conventions on code style formatting, and usage.
- This makes the code easier to read, and it encourages the practice of collective ownership.
Lean Software Development
- Lean software development is a translation of lean manufacturing principles and practices to the software development domain.
- Lean software development is a set of principles that can be applied to software development to decrease programming effort, budgeting, and defect rates by one third.
Our main goal is to eliminate waste and manage the flow of work, Lean is a mindset (not a methodology)
Lean Software principles:
- Eliminate Waste
- Partially done work
- Extra processes
- Extra features
- Task switching
- Waiting
- Motion
- Defects
- Amplify Learning
- learn from what you do and use feedback to keep improving.
- Decide as late as possible
- Make every important decision for your project when you have the most information about it .
- Don’t force yourself decide things that don’t need to be decided yet.
- Deliver as fast as possible
- keep track of how you work, where you’re running into delays, and how those delays impact your team.
- Empower the team
- Help every team member to have access to all of the information they need about the goals of the project and their progress.
- Let the team decide the most effective way to work.
- Build integration in
- the client and development team work together in planning the product.
- This entails a larger planning session at project initiation and smaller session at each iterations.
- see the whole
- when everyone on the team can see what everyone else is doing the team can collaborate on the best way to get the work done.
The methodology that follows the lean principles most is kanban.
Kanban
What is Kanban??
Kanban is a management approach that is sometimes used in agile projects, The object of Kanban is to visualize and optimize the flow of work within a value added chain.
In Kanban we have a board and We have stations like To Do, Doing, Done, the names of the stations can be changed, we can call them, for example, requirements, design, development, testing and deployment.
And the progression of my project happens when those tasks or sticky notes move from the left side to the right hand side of the board.
Kanban Board
Each column shows the station, which is a set of related activities. the items are symbolized by tickets moving from left to right across the board through the stations.
- work-in-Progress limit:
Each column shows a station, which is a set of related activities. the items are symbolized by tickets moving from left to right across the board through the stations.
- Lead Time:
Kanban is used to optimize the continuous flow of tasks by minimizing the (average) lead time for the complete.
lead time start from the first day we start planning until the day we finish, work time is the amount of time we worked in.
The difference between Agile, XP and Kanban
- XP provides guidance on how testing & development should be done.
- Agile teams following Scrum often incorporate XP practices.
- In Kabnan, visualizing tasks is important to provide transparency.
- Iterations in Kabnan are optional
- Timeboxing in Kabnan is optional.
- Scrum doesn’t dictate specific software development techniques.
- Scrum doesn’t provide guidance on how testing has to be done.
- Visualizing tasks is important in Scrum
- Iterations and timeboxing are important in Scrum.
Agile Tools
Jira
Jira Software is an agile project management tool is created by Atlassian company, that supports any agile methodology, be it scrum, kanban, or your own unique flavor. From agile boards, backlogs, roadmaps, report, to integrations and add-ons you can plan, track, and manage all your agile software development projects from a single tool.
We will gonna use Jira as the most famous tool used in Agile.
To begin click on git it free, scroll and click next.
Here i sign up with my google email for free, and then we will create our project using the Scrum template now we will create our first user story using Jira with Scrum Template.
- The first step in our project is to open something that's called the backlog.
- And the backlog is like the requirements of your projects.
- so let’s create our user story in this tool we use it as a type of issue.
- we have four issue type
- Epics: is a large user.
- like if we had a user story needs 40 hours of work it will e an Epic and inside tha epic we will have many user story.
- bugs: problem in the software.
- tasks.
- stories.
We defined the user story as an agile requirement, but is the user stories the only form of agile requirements???
NO
We have five types of agile requirements:
- Themes :
- A Scrum theme is the highest level of the story hierarchy. it describes a view of a tangible product or an abstract goal (such as performance tuning). A product owner further breaks down them into one or more epics. you may group features into themes in your product roadmap.
- it could extend up to a month or more
- Features:
- is a new capability provided to customers.
- Features are part of the product at a very high level.
- it could be extended for 2-3 weeks
- The Epic user story:
- is a medium-sized requirement that is decomposed from a feature.
- it could extend up to 2 days - to 5 days
- User story :
- Requirement that contains a single action.
- it could extend up to 2-5 hours.
- User Tasks:
- Action required to develop a requirement of a user story.
In Jira, you will not find the Themes or the Features but in another tool, you might find them, it depends on the hierarchy of your project and its complexity of it, you should choose from those five types of requirements that fit your project best.
Trello
Is a different agile tools that are available in the market we use it with Kanban methodology, Trello helps teams move work forward, collaborate, manage projects and reach new productivity peaks from high rises to the Home Office,the way your team works is unique - accomplish it all with Trello.
Let’s create a board, the board in Trello consists of lists and each list consists of cards also inside cards we can create checklists and we will see this later.
So for example, if we say that this is a Kanban board and we will follow the workflow of our project through it, we have requirements design, development, testing, pretesting, or debugging, then retesting, then deployment and maintenance.
Inside any card you will find a UI that is very similar to Jira, “if this is a user story, as a user, I want to be able to add items to cart” We can create the acceptance criteria inside it, “we can say given cart is empty when user adds items to cart, then the items will be added to cart”.
I can also, priorities my requirements based on priority, i can use color from label.
This is Trello it’s vary simple, it can be considered as an excellent tool for small scope projects,
Planning in Agile Projects
We have seven types of planning beginning from high level planning:
- Product vision: and the product vision is the main goal of this product, like Uber, Twitter…
- Describe the goals of the product
- Creator: Product owner
- Should be done at least one time per year, Because competitors come into the market requirements change, types of customers might change, the scope will change.
- Product Roadmap: in an application like Uber, we have Uber X, Uber select and Uber scooters.
- high level view of product requirements that create the product vision.
- Creator: Product owner
- Should be done at least two times per year.
- Release planning:
- Plan when and which product increments (versions) get released to the market.
- Creator: Product owner
- Should be done at least quarterly.
- Sprint Planning:
- we divide the project into sprint, each sprint consists of one week, two weeks, three weeks or four weeks, but sprint planning is performed by the whole team.
- Create iterations goals, task and deliverables
- Creators: product owner + Development team
- each one to four weeks
- Daily Scrum
- Discuss today’s tasks that will help in reaching the iterations goal
- Creators development team
- Should occur daily
- Sprint Review
- demonstrate the working product.
- creator Product owner + Development team
- Should occur at the end of each sprint
- Review the product it self
- Sprint Retrospective
- Discusses process and environment and make plans for process improvements in the next sprint.
- Created by the whole team, not only the development team.
- Should occur at the end of each sprint.
Interview Questions
The interview questions regarding the Agile methodology might change based on the position that you are applying to.
These are a general questions might help you to pass the interview:
- What is the Agile manifesto and what are the four values of Agile?
- In 2001, a group of individuals, representing the most widely used lightweight software development methodologies, a greed on a common set of values and principles which become known as the manifesto for Agile Software Development or the Agile Manifesto.
- The agile Manifesto contains four statement of values:
- Individuals and interactions over Process and tools.
- Working software over comprehensive documentations.
- Customer collaboration over contract negotiations
- Responding to change over following a plan
- What are the agile principles?
- The core Agile Manifesto values are captured in twelve principles:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Deliver working software frequently, at intervals of between a few weeks to a few months with a preference for the shorter timescale.
- Working software is a primary measure of progress.
- Welcome changing requirements, even late in development, Agile processes harness change for the customers competitive advantage.
- Continuous attention to technical excellence and good design enhances agility.
- Agile processes promote sustainable development, Sponsors, developers and users should be able to maintain a constant base indefinitely.
- The art of maximizing the amount of work not done is essential.
- Build projects around motivated individuals, give them the environment and support their need and trust them to get the job done.
- The best architectures, requirements and designs emerge from self-organizing teams.
- Stakeholders and developers must work together daily throughout the project.
- The most efficient and effective method of conveying information to and within a development team is face to face conversation.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
- The core Agile Manifesto values are captured in twelve principles:
- What is the sprint and what are the artifacts of the scrum process?
- Sprint is a terminology used in Scrum, used to describe a time-boxed iteration. During a sprint, a specific modules or feature of the product is created. the duration of a sprint can vary between a week or two.
- There are 3 artifacts of the Scrum Process:
- Product Backlog : It is a list that consists of new features changes to features, bug fixes, change to the infrastructure, and other activities to ensure a particular output can be obtained.
- Sprint backlog : it’s a subset of the product backlog that contains tasks focused on by the team to satisfy the sprint goal, teams first identify the tasks to be completed from the product backlog. These are then added to the sprint backlog.
- Product Increment : it is a combination of all product backlog items completed in a sprint and the value of previous sprint increment. the output must be in usable condition, even if the product owner doesn’t release it.
-
How are the Product and sprint Backlog different from one to Another?
Product Backlog Sprint Backlog it’s a list of items that need to be completed for developing the product It’s a list of items to be completed during each sprint The backlog is collected from the customer by the product owner and assigned to the team The team collects the backlog from the product owner and sets up the time frame for the sprint It has a specific end goal It’s specific to a sprint Based on customer vision Can vary based on product vision defined by the product owner It’s independent of the sprint backlog It’s a dependent on the product Backlog The product owner maintains the backlog until the project is complete Each new sprint has backlog added by the team Product Backlog Sprint Backlog It is a list of items that need to be completed for developing the product It’s a list of items to be completed during each sprint. -
What are the benefits of using the a whole- team Approach to product development?
- the use of a whole-team approach to product development is one of the main benefits of agile development.
- Including :
- Enhancing communication and collaboration within the team
- Enabling the various skill sets within the team to be leveraged to the benefits of the project
- Making quality everyone’s responsibility.
-
What are the benefits of early and frequent feedback?
- The benefits of early and frequent feedback including:
- Avoiding requirements misunderstanding, each may not have been detected until later in the development cycle when they are more expensive to fix.
- Clarifying customer feature requests, making them available for customer use early . This way, the product better reflects what the customers wants.
- Discovering (via continuous integration), isolating, and resolving quality problems early .
- Providing information to the Agile team regarding its productivity and ability to deliver.
- The benefits of early and frequent feedback including:
preparing for the PMI certified Agile Practitioner Exam.
- Note The right answer in pink
- Company wide budget cuts require your team to reduce the schedule by three months, the product owner indicates that stakeholders will be angry about the lack of delivery.What should you do next?
- Find a way to keep the project going without alerting the product owner to serious problems.
- Alert the product owner to scope and schedule changes just before they happen so you can make decisions at the last responsible moment.
- Following the methodology rules to inspect the plan and adapt it to reflect the change in budget and schedule.
- What is the most effective way for an agile team to prioritize the work to do during the increment??
- The product owner determines the relative priority at the Sprint Review
- The business representative collaborates with stakeholders to optimize value.
- The team decides which stories are most valuable and gives them a higher priority in the product backlog.
- A Scrum team stakeholder discovers a new requirement and approaches a team member to build it. The team member builds a prototype for the stakeholders who is able to start using it immediately. The product owner discovers this and demands that the team member include him in any future discussions. But the team member feels this is the most efficient way to work. The product owner and team member approach the scrum master to resolve the conflict.What should the Scrum master do?
- side with the product owner
- help the product owner and team member compromise and find a middle ground
- help the product owner understand how the team member is improving stakeholder communication,
- The team members and product owner are having an argument about whether or not a feature can be accepted. They are unable to agree on an answer and the project is now in danger of being late. How can this problem be prevented in the future?
- agree on a timebox length for discussions about feature acceptance.
- agree on a definition of done for each work item.
- agree on a process for conflict resolution.
- Several bugs were discovered by users and the product owner has determined that they are critical and must be fixed as soon as possible. How should the team respond
- add items for fixing the bugs to the backlog and include them in the next iteration.
- stop the project, work immediately, and fix the bugs.
- create a change request and assign bug fixes to a maintenance team.
-
You are a scrum master on a 14-person scrum team, and you notice that the team is having difficulty concentrating during the daily scrum. What should the team do?
- replace the daily scrum with a virtual meeting that uses comments in a social media platform.
- Establish a group norm that requires everyone to concentrate during the daily scrum.
- Divide team members into two smaller teams.
Conclusion
Agile models are based on iterative software development. An independent working module is built after the completion of iteration. Iteration should not take more than two weeks to complete a code. Agile methodologies invite the developers to get involved in testing, rather than a separate quality assurance team.
So if you want to be agile, the first tenet is "Every project needs a slightly different set of policies and conventions or methodology*.*" People's attitude toward communication, user involvement, and frequent releases is more important than the specific process you use.

Top comments (0)