- What do you understand by Psychological Safety?
Psychological safety is where team members feel comfortable taking risks, sharing ideas, and expressing concerns without fear of judgment or reprisal.
Agile teams need a conflict of a different kind - a healthy conflict. The ability to express their disagreement or differing opinion in a way that leads to a better decision making.
- WP, entire teams were summarily dismissed upon faulty or failed production deployment. This became a practice leading to serious job concerns.
- Never ending restructuring in WP leading to psychological safety & health concerns because of proloned uncertainty.
- In AAG, there was this guy, a very senior, who had the expertise, depth of knowledge, and yet a curt, unforgiving, and no-margin-for-error or first-time-right kind of. Business analysts, developers and testers were scared of approaching him. The fact was it never came out in the open during the retrospectives nor at any time in between or thereafter. Not until the final project post-mortem / retrospective. Clearly it was a case of psychological safety where colleagues weren't comfortable sharing their opinion, or view or in a way were muzzled, muffled by fear of judgement.
- How do you empower people to speak out?
> Why don't people want to talk - i could get into a trouble, i don't want to mess up the current team dynamics, i don't want to make a political enemy, i don't care about it, or i am hopeless about it. There could be multiple reasons. Speak to the team and try to understand which of these is it. Hopeless problem or "i don't care" is a much bigger problem. Who's losing it because of this dysfunction. People may think they are not losing it so "who cares".
> Start with "why are people not bringing this out in the public?"
> Next try to understand the impact of it.
> Fear --> try to address it, "I don't care" try to see what can bring in the care, show things can work if proper attention is directed and things are willingly addressed.
> Quantify and make the impact visible (run Retro to expose these issues).
> Look for opportunities when these things surface. Pick up one such opportunity and bring in to discuss.
- Self organising Scrum Team
- Self organisation: A self organising team is one that doesn't have to wait for a manager to allocate work, instead they manage their own work and associated responsibilities and timelines.
- For a team to be self organising, they need to be collaborating, responsive, empowered, flexible / change driven,
- In AAG, nobody waited for another to allocate work. The product backlog was prioritised, and the developers picked up from the top once they were through with their in-flight work. Likewise the testers picked up from the ready to test stream.
- SM enables team self manages and resolve their own conflict.
- Cross functional:
- How do you manage Scope creep in Agile?: In the classical ways of working, scope creep was when a team has agreed to build a piece of software for a given price in a given time frame and then the business changes their mind of what they want, and they ask the team to do something outside of initial agreement. Yet business needs change. In agile, it is not scope creep when you are asking before the team has started to think about the details. It is not scope creep if it doesn't create additional work for anyone.
- It will be scope creep if stakeholders want to swap new work for work already done.
- It would be scope creep if stakeholders want to swap something big for something small.
- How do you ensure productivity in Agile?
Team productivity is a classical project management approach to ensure people are "productive", they are working 100%, are billing 100%.
People work better when they know what their goal is and why! Agile ensures transparency due to which people know their sprint goal, product goal, product roadmap and the product strategy behind all of it and how it ties with the product vision.
- Not consistently delivering - velocity
- There could be multiple reasons why teams are not delivering consistently, or delivering small - Team composition and skill sets, extent of team collaboration, effectiveness of communication to clear barriers, scope change, technical debt. etc.
- In AAG, for the first few months, the velocity was abysmal. The business complained. Fact of the matter is the application was extremely complex, the code itself was old and complex too, so the dev teams took a while to surmount the learning curve. Over a period of time, what used to be a less than 30 story points, picked up momentum and the team started delivering an average of 60 story points per sprint.
- Common Antipatterns I came across
- Line managers are attending daily scrum. This has created performance pressure.
- Project manager attends the daily scrum and gives instructions.
- Account manager (of vendor delivery team) attending scrum, and making space for comments, offering advise, etc.
- Project manager running the estimation session.
- Absent PO, or partially available PO.
- Un-empowered PO
- Moving user stories from one sprint to another; not really committing to sprint goals. Flexible sprint goals repeatedly.
- Forming, Storming, Norming, performing
- Tuckman's stages of team development.
- Forming - little agreement, unclear purpose
- Storming - Conflict, increased clarify of purpose, power struggles
- Norming - agreement and consensus, clear roles and responsibilities
- Performing - clear vision and purpose
- Adjourning - task completion
- Agile mindset - based on the 4 values and 12 principles.
- Respect
- Collaboration
- Continuous improvement
- Focus on delivering value
- 4 values and 12 principles of Agile
- 4 values
- Individuals and Interactions Over Processes and Tools
- Working Software Over Comprehensive Documentation
- Customer Collaboration Over Contract Negotiation
- Responding to change over following a plan
- 12 principles
- Customer satisfaction through early and continuous software delivery
- Accommodate changing requirements throughout the development process
- Frequent delivery of working software
- Collaboration between the business stakeholders and developers throughout the project.
- Support, trust, and motivate the people involved
- Enable fact to face interactions
- Working software is the primary measure of progress
- Agile processes to support a consistent development pace
- Attention to technical detail and design enhances agility
- Simplicity
- Self-organising teams encourage great architectures, requirements, and designs
- Regular reflections on how to become more effective
- How big was the team, was it collocated?
- 5 developers, 2 testers, 2 BAs. Distributed.
- Any specific rituals?
- Project kick off / user story mapping
- Daily stand up, sprint review, sprint retrospective.
- Backlog refinement (Once a week 2 hours).
- Sprint planning.
- User story hand over sessions (BA).
- 3 Amigos for specific user stories.
- How do you prepare for sprint planning sessions?
- Conduct weekly backlog grooming sessions (Wednesday's). With PO / BAs, team. This ensures the backlog is prioritised, and estimated.
- Refer the roadmap and see how the delivery is going, something needs to be included etc.
- Calculate sprint capacity based on team availability (leaves, resignations, etc.).
- I usually prefer a prepared PPT deck with all the information.
- Refer to Jira and see the progress of in-flight tickets.
- Finalise the sprint user stories, and sprint goal.
- Commit to the sprint.
- Some live examples of sprint goals.
- When we trigger hailstorm alerts, the SMS alerts are sequenced and sent to customers.
- Referral trigger and referral suppression work as expected.
- What tools have you used for sprint management?
- Jira, Confluence, MIRO for user story mapping, Fun retro, Pointingpoker.com for estimation
- Walk thru of scrum demo / review session.
- Schedule it on the last day of the sprint.
- Attended by PO, Business and important stakeholders as required.
- Have a pre-planning meeting with the team on what will be showcased, who will showcase, and how will they showcase.
- Starting of sprint review a quick overview of what is being demoed, etc.
- Then the sprint demo / review takes place and feedback sought. Feedback is taken and incorporated for planning.
- Retrospective formats I have used in the past:
- What worked, kinda worked, and did not work
- Sad, Mad, Glad
- Hot air balloon
- Boat - what propelled you, what held you back.
- etc.
- Retrospective
- Go thru the previous action items
- Run the retro
- Identify and capture action items, person responsible for the action and commit on a date.
- High-performing scrum team - AAG
- Collective ownership
- Cadence / frequent releases.
- High velocity
- Highly skilled technical, cross functional teams.
- Commitment to sprint goals
- Trust and mutual respect
- Continuous learning
- Self organising
- Clear understanding of where their work fits within the organisational context
- Understanding and acknowledging the release dates
- Clearly defined roles and responsibilities
- Personal excellence
- Healthy conflict (this was missing)
- Psychological safety (this was again missing).
- There is a senior guy who keeps information to himself, is uncooperative; how will you tackle him?
>
- Team does not feel motivated. How will you deal with the situation? OR How do you motivate your team?
> Get to know the team
> Understand what they are passionate about
> Understand how they want to be recognised
> Tap into people's intrinsic motivation.
> > Give people control over their work
>> Provide opportunities for challenges and mastery (Hackathons).
>> Aligning their work with a higher purpose
> Speak to senior management to see if something can be done. We gave away AUD 100 and AUD 25 during the past one year as a way to keep team motivated.
- There are a lot of defects coming up. What will you do?
> Gather data to understand where exactly the defects are coming (Module / specific functional area, part of the code, which environment, etc.). Do a root cause analysis.
> Speak to PO.
> Try to see if automation is there and is effective.
> Come up with a strategy to deal with the defects.
> Implement the solution, track and monitor to see improvement.
> Get an understanding from PO whether she's okay with it.
- How would you handle a new team?
1. Understand Stakeholders
2. Deploy / activate process
3. Understand technical side of things
4. Understand business side of things
5. Focus on being agile
Understand stakeholders
--------------------------------
There is a key need for myself to be able to be accepted by the team, secure their trust and goodwill. I will first embed myself into the team and observe the team members. I won't start with anything agile yet. This exercise will tell me a lot about the current team dynamics, their motivation levels, expertise, what will and won't work for them, etc.
I will then set up a one to one (recurring) and try to know them, their interests, motivation, expectations, etc.
Deploy / activate process
> Team up with the Agile Coach to understand and implement the organisational framework
> Set up learning sessions
> Define the type of agile you want to implement, define the sprint length (for Scrum)
> Establish and run the key scrum events (Scrum) or other events (Kanban, etc.)
> Set up a working session and come up with Team Playbook / working agreement.
This will consist of
-- How the team members will work together.
-- What time will the stand up happen?
-- What will be the modes of communication
-- How will you let you know your availability thru Teams or another collaboration tool?
> Set up Jira and other tools
> Ensure team is "Doing" agile
Understand technical side of things
> Understand the technology, tools, etc.
> Understand the project from technical side of things
Understand business side of things
> Thoroughly understand the business processes and business side of things required for the project
Focus on the Being part of agile
- Focus on team developing an agile mindset - team should be able to cultivate the Agile Mindset which is critical to success of agile development
- The three pillars of Empiricism are - Transparency, Inspection and Adaptation
- What are some of the common agile metrics you have used?
> Velocity
> Sprint burndown
> Epic and Release burndown
> How frequently do you release to production?
> Defects in Dev, SIT and UAT
- What is your typical daily schedule?
> I start of early 8am within city, 8:30 north sydney.
> Catch up with the defects, Jira and dashboard
> Catch up with all emails, production alerts, failure alerts, etc.
> Interaction with the team
> Running the standup
> PO / BA catch up based on need. But BA catchups are quite frequent.
> Upstream, downstream, dependency checks with other teams
> Change, release checks
> Preparation for scrum of scrums
> Preparations for ROAM
> Preparations for community of practice
> Preparations for weekly dashboard reports
- How have you mentored and coached the teams?
Mentor is a trusted guide, a wise counsel. Someone skilled in a specific domain. I am in the Agile ways of working. There have been occasions in the past where a new team was totally new to the story point estimation; they required training as well as some kind of hand-holding / mentoring.
- What are the various roles of a scrum master
> Teacher
> Mentor
> Coach
> Facilitator
- What are the key challenges you have faced as a srcum master
> People are unwilling to change. / > Don't get a buy in from the team. Have one-on-one to understand what motivates each. For example in AAG, there were a few highly skilled resources who have been in the org for 15+ years and absolute masters in their field. They needed a way to express their talent and skill. Hackathons provided a good opportunity for them. They contributed, and stayed motivated.
> Avoid overly long sessions. Team decided not to have any meetings more than 2 hours at a stretch. Intersperse with fun activities.
> Coffee talks and lunch outs / lunch talks. Coffee catch ups were a regular feature; occasionally we encouraged people to join remotely over lunch for unofficial chat.
> "Hurt the butt" catch ups on Fridays. CTP team. Intent was to hear from each member what was it that hurt them most (in terms of the project) during the week. What was it that was the most challenging and left them exasperated / fuming. Conversely, one could also discuss what was it that overawed them too.
> Sometimes due to lack of transparency, especially during restructuring, there are concerns and apprehensions about jobs / role redundancy. (Give Telstra example)
> Tech lead doesn't listen, is not supportive, and bosses around. Personally, I don't like to have a hierarchy within my team. However, there may be situations where there is a need to have a tech lead within the team in some companies, just as they would like to have a test lead or an automation lead. So, I had this big-ego guy that sort of derailed every stand-up because of his unavailability. Realised this soon after I joined the team; after a few days, had a personal chat with him to understand his situation. Turns out his spouse was carrying and he therefore had to get the kid readied, drop her off at the school and do a bunch of other chores at home. That meant, he had little time, and if he did, was much constrained for the daily stand ups. We tried if a remote call would help. Soon after we realised that wasn't working. The only option was to again check with the PO to see if we could instead push the standup to 11:30 against the company practice. It was a one-off and we had our fair reasons. The PO heard, empathised and was in all support.
- Product Owner / Business is forcing to push more work, or pick up more user stories, or increase the velocity
> Project runs healthy, people are not burnt out, and the customer / stakeholder is also happy. This is the end goal we try to achieve. So, when we have a customer or business that is insistent on pushing more work, we have to understand why it is so. What exactly is prompting the customer to act that way. Mutual empathy should help. Go to the PO and first understand the need.
> Talk to the PO and help them appreciate the team constraints, yet also identifying the need and see what best can be achieved without the team getting burnt. If it is a high priority work, for example the Covid riders we added on the insurance policies recently, then it is something that MUST be done no matter what. That is business criticality which can't push back. Even if it means the team works 15 hours. That is a one off and should be okay.
> Software development is a create process that requires collaboration, so pushing or bargaining doesn't help. Mutual empathy and realisation of needs helps solve things.
> Difficult to run the show without transparency and trust.
- Example of Epics and user stories from your recent past
Epic = Reporting
US1 = Cover report
US2 = Referral report
Epic = New Business, Endorsements, Renewals, Cancellations, Mid-term Alterations
US1 = Create NB
US2 = Update NB
OR
Epic = July Release
User stories = a bunch of related user stories that need to go as part of the Jul release (BAU situation).
- What are the improvements you have done in your agile team?
> Improvements are always team effort, especially so in Agile. Communication, coordination, balance of team contribution,
> Increased productivity. Beginning of the project velocity was 30 to 35 story points. After 6 months, production was averaging at 70 story points.
> TDD / Test first approach / shift left. Team made it mandatory to start with automated testing first approach, as well as a shift left with testers pairing up with developers during story development - coming up with scenarios, writing DROOLS Business Logic, as well as regression scenarios and test cases for the user story such that by the time the user story was ready, the tests were ready as well.
> Increased focus on technical debt. We took a pause to understand reasons for increased build failures, longer set up times, frequent environment failures etc. Then reworked on improving / moving modules, changing configurations, etc. to ensure the application was faster, reduced the number of regression tests / optimised the regression suite, and also stabilise the application set up.
> Wilful participation in hackathons to ensure the motivated members of our team are able to exercise their skills in organisational innovation.
> Ensure team learnings / tranings are always captured / recorded and archive them for posterity. And capture technical changes / configuration changes etc. on Confluence for similar reasons.
- Project team is consistently failing to achieve sprint goal. How do you manage this situation?
When answering acknowledge that this is a hypothetical situation as you don't know anything about the team as such. Also there could be several reasons or a bigger problem lurking behind this symptom.
> Two possibilities - I am new to the scrum team, and the second situation is I am already a scrum master in the team.
> When I am new to the project I wouldn't know the history of the project. Was this already recognised as a problem in the previous sprint retrospectives? If yes, what was the outcome of those retros and what has the action items led the team to? If not, then ensure we have a retrospective where these items are discussed.
> Over-commitment could be a possibility. PO pushing and the team agreeing could also be a possibility.
> Manage WIP. Pick up moderately with clear stretch goals identified. Don't over commit.
> There could even be inter team dependencies that could have led to this situation.
> Retros will identify such issues.
> Agree with PO on definition of ready - take only those items into the sprint that have their dependencies resolved in the previous sprint.
- PO is allocating the work and pushing team to complete work.
> PO may be unaware of agile ways of working. Have a chat and clarify.
> PO is not confident as the team has been faulting on delivering the sprint goal for the past few iterations.
> PO may want to experiment a particular feature and as a one off wants team to deliver. Again have a chat with PO, understand the priority, intent and how, what and when deliveries need to happen and decide accordingly.
> PO may be having a push from the business to deliver, we don't know. Again, have a chat with PO to set expectations.
- How does your playbook / working agreements look like?
- How do you tackle conflicts within your team? Especially during pandemic situations. Example team availability, as every person may like to work at different times.
> Agile is a process of co-creation. You will need to cooperation and collaboration of other team members, their guidance, their availability to complete your part of the task that ties to the larger piece of work. It is therefore imperative to be able to work during similar times / with overlaps.
> If work times, next day schedules are becoming unpredictable, then
> Revisit working agreements. (as there is no office environment anymore).
> What happens when someone takes an emergency leave. How do they communicate, handover etc.
> How do you communicate on the common channel your availability - when you log in, when you log off, when you are away, etc. etc.
> When to call, when to WhatsApp, etc.
> This way it is more predictable for others as well as they are aware of specific unavailabilities.
- One of the team members is lying about estimates. Worked for few hours but estimated for a couple of days. How do you deal with this?
> Use transparency as a team.
> Is the work item available to everyone?
> Use sprint planning / estimate as an effective tool.
> Create an environment where people challenge one another.
> If a particular person is always taking more time than others for his piece of work, have a conversation to understand why. Is it lack of understanding, lack of skill, etc. etc.
> Does developer pairing help? Check and see.
- How to increase team velocity?
> Velocity is an observation rather than a target.
> If there is a stability, then work is predictable. That there is no variability left.
> Find out reasons why.
> Why is there a consistent velocity.
> Are some contingencies planned. (team might be adding contingencies in their planning).
> Complexity, tech debt, or defects could decrease the velocity. Ensure the discussion is able to capture the reasons why and let the team plan for how to.
- If you are helping move a team from waterfall to scrum, how will you ensure they don't end up continuing to do the same old way of working?
> Either pickup a hypothetical scenario or can bring in something from experience.
> In TFS, there was this project manager who used to manage the same project which has since moved into an agile way of working. Now this person would attend daily stand ups, start dictating terms, and demand answers from the team, tech lead, etc.
> Have a conversation.
> There was also an independent testing team, a third party which was different from the client, and the vendor development team.
- How would you handle an old team vs. a new team / If you onboard, what are you going to do - you have two teams - one is new and another is old. (new is totally new to Agile, old has been on it for quite a while and good at it).
New Team
> First thing to do is to gain their trust and respect. To be welcomed into their fold before embarking on any improvements. It will take a while though. For this I will have frequent individual catch ups (I prefer individual one-to-one every week and then move to fortnightly until the team is stable), set up coffee catch up sessions, lunch catch ups if the team is willing. Ensuring some Team Building activities - Book or Technology Club, "What Sucks" catch up on fridays, etc.
> Observer how things are going.
> Gather information on team skills, competencies and who's on what and how it all fits together
> Catch up with all stakeholders to understand the expectations from the team - business, product owner, service owner, and any other stakeholder.
> Catch up with product owner frequently
> Catch up with technical lead frequently
> Start with working agreements. How, when, what etc. etc. This will also set up expectations as to what the team can expect from me, my functioning style -- Meetings, Mode of communications, sprint events, length, participation, how do we let know our availability, leaves and emergency leaves. management expectations from the team, etc., definition of done, definition of ready, etc., any other business.
> Agree on Scrum / Kanban, length of sprint, etc.
> Introduce the organisation framework and the expectations from the agile transformation team. Probably also include the agile coach or let her drive this (maybe).
> User story mapping - May have epics already from the program team OR facilitate customer journeys to flesh out the features and epics.
> Set up Jira board.
> Set up team events - daily stand up, sprint backlog refinement sessions, sprint planning, sprint review and sprint retrospective. Also consider story hand over sessions, 3 Amigos.
> Get a detailed domain and technical deep dive into the project.
> Run the show
Existing team
> Same starting stuff as before. > First thing to do is to gain their trust and respect. To be welcomed into their fold before embarking on any improvements. It will take a while though. For this I will have frequent individual catch ups (I prefer individual one-to-one every week and then move to fortnightly until the team is stable), set up coffee catch up sessions, lunch catch ups if the team is willing. Ensuring some Team Building activities - Book or Technology Club, "What Sucks" catch up on fridays, etc.
> Understand and reflect on the team competencies, skills, number or resources, etc.
> Frequent stakeholder catch ups - product owner, business, tech lead and other key members.
> Take a look at the recent retrospectives to understand some existing team issues.
> Observe, ask, and reflect on what the team is achieving and where it is headed.
> Two competing interests would be to apportion time between project work and business as usual work. 20% 80% is okay, or based on the work what percentage on which work will work best for the team. Have a discussion around these and let the team decide.
> Get a detailed domain and technical deep dive into the project.
> Arrange for the scrum events and calendar them up.
> Run the show
- What is the difference between product backlog refinement session and the three amigos?
> BA writes user stories in conjunction with PO and stakeholders
> When complete it is put fwd to 3 Amigos
> BA + QA + Tester discuss and US is fine tuned
> Then goes to Backlog refinement and sized accordingly after further dicussions.
> Goes to planning session, picked up for sprint.
- What motivates you?
> Learning (new things).
> Challenges (are like puzzles)
> Social and intellectual discussions
Which three words best describe you?
> Methodical
> Empathetic
> Go getter
- Only when a bunch of your user stories are combined do they deliver value. Each user story doesn't. Is it right to bunch them up so they deliver value?
Scrum expects that each iteration has an sprint goal. And that iteration probably might have some business value. Nowhere is there an expectation that each user story should deliver business value -- User stories should be DEEP and follow INVEST. Each increment can. Bundling user stories together increases their size, which many not always be possible to deliver in the same sprint.
There may be a possibility that your sprint does not have a sprint goal, which defines the business objective of that sprint.
- How do you handle absence in scrum?
> Team playbook will probably give a clue about how to deal with the situation.
> When coming up with team playbook / working agreements, consider the scenario of what happens if someone within the team goes on an emergency leave, or quits. How should the team ensure there is business continuity?
> Discuss first with the team if that user story being worked on by the member can be absorbed as part of current sprint.
> Also identify other impacts of the emergency absence.
> If the team cannot absorb the work, discuss with PO the subsequent options. Is it okay to push the item to the backlog? If not, should the team pick this one up and accordingly drop a similar size item from the backlog?
> Each planning should ideally plan for contingency - about 15% of time. (based on the available hours).
> Some people use focus factor (ratio of story points to actual hours).
- Team is trained in hours to estimate work. As an SM how will you coach the team to use story points.
> Quite common for teams in waterfall and those moving from waterfall to agile to estimate in hours.
> Estimating in hours is absolute estimate. It's a known fact that we humans are pretty bad in estimating. We are either over-estimating or under-estimating things.
> In agile we focus on relative estimation. It's much easier for us humans to relatively size something with respect to something else.
> The central essence of agile is to release a new feature quickly and be able to get a feedback on it. And this goes on indefinitely. Essentially we will end up with a fixed cadence where we are able to consistently deliver with an x amount of work. That x is often the story points.
> In agile we also ensure that we prioritise the user stories such that anyone in the team is able to pick up an item and work.
> When using hours, each person may take different completion times, therefore what we capture as part of the user story (hours) may not be relevant to all. Consequently, it's easier for team to agree on and work if there is a relative estimate such as story points. A 5 pointer might mean (within the mind of a particular developer) 5 working days, whereas for another it could mean 3 working days; however both agree that it is a 5 pointer.
> Absolute estimation works for items that are similar to tasks that have already been worked in the past. For new items, it's much difficult to estimate how long it takes to completion.
- There is a request from delivery head to extend the length of the sprint from 2 weeks to six weeks. How will you deal with such a situation?
> It's clear the delivery head understands the spirit of agile. Or what a cadence means and why it is important.
> First go and speak with the delivery head to understand why the request is coming from him to extend the sprint length.
> Explain cadence and the reasons based on which you had decided that the sprint length should be 2 weeks.
> Make him / her understand the organisational cadence / or the cadence of teams in a release train or within a release (if not using SaFe) and why it is important to adhere to a fixed cadence at organisational level.
> If the delivery head relents, good. Else, speak with the PO and arrange for a common forum with the delivery head, PO, and the business stakeholders and take it up from there.
- As an SM, how will you ensure all your events are running fine? How will you train your team?
By identifying anti-patterns in the sprint events. These are deviations from the expected.
Sprint review
> Sprint review is not sprint Demo. This is not a demo. The intent is to showcase to get feedback from customer / business (INSPECT) and then take a look at the product backlog to see what has changed / been requested, add / delete / modify (ADAPT) based on the sprint review.
> Sprint review is not done.
> Sprint review is conducted as a reporting session - thees many user stories, these many bug fixes, how much money was spent etc. These should not matter. What should matter is what are the learnings? Are we still on the right track? Do we need to change?
> Death by PowerPoint. Avoid a PowerPoint presentation.
Daily stand up
> Team members report
> Very long stand ups where just about everything is discussed
> Problem solving during stand ups.
> People skip because of time zone difference, or not everyone attends
> Overly focused on yesterday; no plans for today.
Sprint planning
> Team over-estimates its capacity and takes in too many items / tasks.
> Team ignores to address technical debt
> Team does not add slack time / contingency time. (Ideally is 60% for new, 20% slack and 20% for bugs and tech debt).
> Too little or too much of planning
> Some people skip the planning session
Sprint retrospective
> Sprint retrospectives don't happen
> Action items don't come out of the retro and action items are not tracked - they don't feedback into the planning and thus no effective mechanism in place for ADAPT.
> Cancelling sprint retro if more buffer time is needed to achieve sprint goals.
> Rushed in retro / quickie
- What is included in DoD?
> Definition of Done is a shared understanding of what Done means and is created by the development team.
> DoD is at several levels
- DoD for a User Story ( Is called Acceptance Criteria)
- DoD for Sprint
- DoD for Release
Sample Definition of Done.
> Code has been reviewed
> Unit tests have been written and code has passed all UT
> Design doc has been updated.
> User stories have been tested
> Test coverage is satisfactory
> There are no pending defects
- What is acceptance criteria, and who sets it?
Acceptance criteria is the DONE criteria for a User story and is set by the Product Owner / Business Analyst (In consultation with PO). AC tell us the functional and non-functional checks that the user story has to pass thru to be considered done.
Example of AC for a user story. Acceptance criteria is usually written in the Given, When, Then format.
US = If the Year of the Vehicle make is before 1960, reject the request with a remark "Invalid Year. Request rejected".
Acceptance criteria - 1
Given the broker makes a request with year of manufacture of the vehicle as prior to 1960
When the request is sent to EMBS
Then EMBS should decline the request with a message "Invalid Year. Request rejected."
Acceptance criteria - 2
Given the broker makes a request with year of manufacture of the vehicle as 1960
When the request is sent to EMBS
Then EMBS should REFER the request to BPM
What is a cross-functional team?
A cross-functional team is a team that is organised around a product, and has all the skills required to deliver the product. The team members may include business analysts, UI/UX designers, Front end and back end developers, quality analysts, and Dev Ops engineers.
No comments:
Post a Comment