Strengths:

 Communication – keep everyone on the same page

 Empathize with people/situations and support them in doing their best
 Hands-on checking of work completed by the team

Improvement
 Public speaking
 Pushing team to the limits on work and performance.

Agile Methodologies propose incremental and iterative approaches to software design.

The agile practice has grown vast in all the platforms. There are various Agile methods present in
Agile testing. One of the major practices one is SCRUM, so let’s investigate the process, Roles,
Responsibilities, and the Artifacts involved in Scrum.

ROLES

Scrum Team
- Team is cross-functional and consists of 5-9 people
- There are no set project roles within the team
- Team defines tasks and assignments
- Team is self-organizing and self-managing
- Maintains the Sprint Backlog
- Conducts the Sprint Review

Product Owner (PO) Scrum Master (SM)

- Accountable for product success - Holds daily 15-minute team meeting (Daily
- Defines all product features Scrum)
- Responsible for prioritizing product features - Removes obstacles
- Maintains the Product Backlog - Shields the team from external interference
- Insures team working on highest valued - Maintains the Sprint Burndown Chart
features - Conducts Sprint Retrospective at the end of
a Sprint
- Is a facilitator not a manager

ARTIFACTS
Product Backlog (PB)
- List of all desired product features
- List can contain bugs, and non-functional items
- Product Owner responsible for prioritizing
- Items can be added by anyone at any time
- Each item should have a business value assigned
- Maintained by the Product Owner
Sprint Backlog (SB)
- To-do list (also known as Backlog item) for the Sprint
- Created by the Scrum Team
- Product Owner has defined as highest priority

Burndown Chart (BC)

- Chart showing how much work remaining in a Sprint
- Calculated in hours remaining
- Maintained by the Scrum Master daily

Release Backlog (RB)

- Same as the Product Backlog. May involve one or more sprints dependent on determined Release
date

MEETINGS
Sprint Planning: synchronize their work
- Product backlog prepared prior to meeting
- First half – Team discuss about PTO plans for
the sprint and Spilled items from previous
Sprint stories\Bugs\Tasks.
- Second half - Discussion on upcoming Sprint Review:
stories and its assignment and its story point. - Team presents “done” code to PO and
-Tasks created / assigned – Sprint Backlog stakeholders
produced - Functionality not “done” is not shown
- Feedback generated - PB maybe
Daily Scrum: reprioritized
- Held every day during a Sprint for 15 - Scrum Master sets next Sprint Review
minutes
- Team members report to each other not Sprint Retrospective:
Scrum Master - Attendees – SM and Team. PO is optional
- Asks 3 questions during meeting i.e. Last 24, - Questions – What went well and what can be
Next 24 and any impediments improved?
- Opportunity for team members to - SM helps team in discovery – not provide
answers

PROCESS

Sprint Planning -> Product Backlog -> Sprint Backlog -> Sprint (Daily Scrum -> Walkthrough\Dev\
Handsoff\Design\Execution\Sprint review ->Sprint retrospective) -> Product Backlog.

=====
Having observed and participated in more than 15 SAFe PI Planning sessions, the
following are some of the Anti-Patterns I have observed - generally in the earlier phases
of SAFe implementations (First or second PI Planning session). Some of them seem to
continue even after a while. I am sure this ground has been covered but perhaps worth
refreshing now and then.

1. Not having (enough) Features ready

2. Features not prioritized properly
3. Features not socialized with teams
4. Inspect and Adapt - Improvements not incorporated into Backlogs or Plans
5. Not validating that Features can be done in one PI
6. Not ensuring that Business Owners attend/participate
7. Logistics not well sorted ahead
8. Teams think PI Planning is about detailed Planning and not about
Alignment/Commitment
9. Teams not having calculated capacity well
10. Teams are unable to finish planning because they get into way too much detail
11. More focus on estimates and less on dependencies/risks
12. Dependencies not committed to by teams
13. Program Board does not reflect the deliverables/dependencies
14. Poorly articulated objectives
15. All objectives get a value of 10 from Business Owners
16. ROAMing process is not efficient. RTE ends up owning most Risks
17. Too many uncommitted PI Objectives
18. Too many PI objectives
19. People worried about using confidence vote properly
20. Previous PI Planning Retro feedback not incorporated into current PI Planning
prep
21. Insufficient attendance and engagement from Shared Services and other
stakeholder teams
22. RTE not getting on top of teams that are struggling with Planning and not
ensuring enough support

Metrics:
1. Predictibility

 Scope Variance: The number of story points delivered / story points committed. Velocity charts are very
helpful, but while velocity gives a measure of development capacity and delivery trends, this variance
demonstrates the number of story points carried over from sprint to sprint or missed all together. Essentially,
this is functional debt.
 Release Velocity Variance: The current velocity / average velocity. Similar to acceleration, this indicator
gives a sense as to the overall pace of the team. If we are slowing down (negative variance), then there may
be trouble ahead.
 Escaped Defects / Story Point: Also called defect density, this indicator will show whether the team is
sacrificing quality for speed or quantity of output.
 Business Value Variance. If you are capturing business value as defined by your product owner or other
business stakeholder, then this metric will indicate story selection tradeoffs. This metric will indicate if the
group had to include more low value stories than expected due to technical or other valid reasons.
By averaging the variance metrics, we can create an overall index and then plot the predictability of each release as a
trend, as shown in figure 2. Ideally, the trend will be positive and the teams will improve their predictability over time.
Downward trends are opportunities for exploration.

2. Productivity
Predictability alone is a useful metric, but it’s not ideal to be predictably slow. Marrying predictability with productivity
measures gives the team and stakeholders a good indication if they are improving their delivery or if they are slowing
down to be more predictable. The Cumulative Flow Diagram shown in figure 3 is a good chart for measuring
productivity.

Figure 3: Cumulative Flow

Diagram
The advantage of the Cumulative Flow Diagram is that we can easily see, in one chart, the relative work in progress
of each of the major functions of an agile development team, as well as its total throughput. Story points that have
been elaborated, developed, tested, etc., are all shown in different colors in the area chart. The slope of the curve
can be a good measure of productivity or potential waste if one of the teams is “outpacing” the others.

As the lines diverge, there may be too large of a backlog in any area (potential waste). Lines coming together may
indicate a potential bottleneck. Flat lines or low slopes on the chart indicate a stalling of productivity of that part of the
development process. The slope of the bottom line is a measure of story points delivered or throughput. The steeper
the slope, the more effective the team in delivering stories. Be sure to limit the number of story point possibilities (we
typically use 1,2,3,5) for each story in order to limit the possibility of gaming the system.

Acceleration is another effective metric for productivity. Essentially, acceleration measures the current velocity
against the mean velocity. Is the team doing better or worse than usual? Plotting acceleration on a curve will
demonstrate the team’s trend. Using sprint and release velocity trend lines as a measure of acceleration is another
approach that many companies take; this approach is perhaps simpler. Plotting the average and standard deviation
from the average can show clear trends in output.

By combining views of predictability and productivity of the development activity, the team and its stakeholders can
quickly and easily tell if the development is on track, if predictability is improving, and if team members are self-aware
enough to improve their overall output.


Explain Agile to me in 30 seconds or less.

 Tell me 4 of the 12 Agile Principles

 If you were to choose 1 Agile Value to instill in your team, which one would it be and why?
No right or wrong question, just seeing if they give me one of the Agile Values and not Scrum
Values.
Focus: Everyone focuses on the work of the sprint and the goals of the team. Focus helps
avoid distraction
 What is the Empirical Process?
 What are the Scrum Ceremonies a Scrum Master is responsible for?
 What is your current involvement as a Scrum Master?
 How long are/were your sprints?
 Is it okay if someone wants to change a requirement?
 How many Scrum teams have you managed at one time?
 What kind of Agile frameworks besides Scrum have you used?

what is the best method you have found to make blocked stories visible on your Sprint/Kanban
board?

The first is to use the "flag issue" functionality. This turns the issue card yellow in the backlog and
board. This makes it stand out and highlights that the team should be doing something.
The other thing I like to do is to turn on the "Days in column" setting on the Card Layout
configuration for a board. This adds a row of dots that change color from green to yellow to red
based on how many days a card has remained in the same column. It's not quite as obvious as the
flag, but it may help you find issues to flag as being blocked or impeded.

Days in columns is a feature that can be enabled or disabled on board settings. To enable or disable it
you'll need to have jira-administrator or project-administrator permissions on the board.
Click on the three dots icon on your board > board settings > Card layout
You'll see the option to show Days in columns.