Category Archives: SDLC

Seven Interview Screening Questions for an Agile, Project Manager

It seems like only yesterday I was on the other side of the table, asking interview screening questions to perspective project manager candidates.  Here are seven interview screening questions I was asked earlier this week for an Agile, PM role, and my answers.

Background:

I’d consider myself an Agile Project Manager rather than a Scrum Master.  Differentiation?  I see the Scrum Master role as a coach / facilitator to help the team function using the Agile / Scrum methodologies.    The agile PM role, in my mind, does the coaching/facilitation as well as filling the traditional role as the PM.

Questions:

1.  What is the duration of the Sprint Cycle?

On scrum teams I’ve lead and been apart of in other capacities, its ranged from 1 to 2 weeks, but mostly two week sprints. In one instance, we had two week sprints, and then just after our major release to our client, we set the sprint to one week duration so we could incorporate client feedback ASAP.

2.  What are the various Agile ceremonies you conduct from day one to the last day of the sprint?

Project Kickoff – not necessarily limited to Agile, but is a project ceremony to get the team acquainted with roles and responsibilities, understanding scope at a high level, and the overall project duration expectations.

Initial Combing the Backlog with the Product Owner, and Tech lead(s) to identify priority backlog stories, and technical dependencies for the initial sprint(s), potentially looking ahead to 1+ sprints

Sprint Open #1 (all matrixed team members partake) In this meeting there are a number of activities that may occur:

  • Reviewing the Backlogwith the team in business priority sequence.  Fleshing out the user stories’ definitions, where required, enough to score each story
  • For each User Story in the Backlog prioritized for the current sprint, the team mayperform an efforting exercise to derive the ‘story points’. Playing Planning Poker is one way to derive story point estimates
  • Each of the story point estimates adds up to determine the potential velocity for the sprint, or team output potential
  • User stories assigned to the current Sprint are ‘Accepted’by the team for implementation in the first sprint, and are assigned to team members. e.g. for coding, doc, infra, or additional vetting, such as Architectural Spike stories.
  • Product Owner, Project + Technical Lead(s) decide beforehand how long sprints will take, and roughly thepotential velocity of the team based on all story points in the Sprint.
  • Sprint Open will commence, and any tool used, e.g. JIRA Agile, will enable the Agile PM / Scrum Master toinitiate the Sprint in the SCRUM / Kanban board.  All user stories are set to an initial state, e.g. “To Do”.

Agile Ceremonies Continued…

DSUs, Daily Standups, or Scrum sessions.  Traditionally, 15 minute sessions primarily to uncover BLOCKERS, and help each of the team members to remove their blockers.  Also, discussed, work from prior DSU, and current work until next DSU

(Optional) At the ending of each sprint, a day before Sprint Close, a Retrospective meeting is held, i.e. what did the team do well. what can they do better

Combing of the backlog for the next Sprint with the Product Owner, and Team Lead(s) e.g. re-evaluate priorities; e.g. 2 uncovered additional Stories / Tasks required for Sprint #2

Sprint Close #1 / Sprint Open #2 – Many times Sprint Close, and Sprint Open are combined, or may be separated depending upon the scope of the sprints.  I’ve sat through 4-5-hour Sprint Close sessions.  The Sprint Close may have each of the stories marked as status ‘Done’ reviewed by the team including the Business Product Owner.  A demonstration of the User Story, if applicable, may be performed, e.g. a new button function.  The team demo may occur by anyone on the project team.  The product owner may be required to move the status of the user story to ‘Accepted’ as a final status.  Additionally, burn down charts, and other visual aids may be provided to the team to uncover the team’s projected velocity on par with actual results, and lead to projected effort adjustments.

Sprint Open #2, similar activities to Sprint Open #1.  Team will see what stories they planned to complete, but did not.  Should the team push these stories to the next sprint, or to the backlog for future implementation.

Each sprint in the strictest sense, the content delivered should be ‘deployable’, a commitment to release work into target environments (e.g. Staging, Prod)

3.  When a project starts, how do you figure out the project scope?

Some projects with ‘external’ clients have a clear definition of project scope in the statement of work (SOW).  Other times a Product Owner may have a list of items solicited from product stakeholders.   These are two possible inputs to the ‘Product Backlog’ maintained in any Agile/Scrum facilitation tool, such as JIRA Agile, or Microsoft’s Team Foundation Server (TFS).

Combing the Backlog with the product owner, and tech leads may enable the team to add more details / definition to each of the User Stories in the Backlog.  In some cases, team leads may assign user stories to an Architect or Developer for the purpose of refining scope, and adding ‘sub-tasks’ to the user story.    In addition, some project scope needs to be defined and refined through ‘Architectural Spike Sessions’.

4.  If a Scrum Master is [managing] multiple projects, do they follow the same process for each project?

It helps if a consistent process is followed across scrum projects to eliminate confusion, and potential work across projects.  However, following a consistent process is not required, and there may be business or technical reasons to alter process.

5.  What kind of reports do you create in your Agile projects? Explain the reports.

Burn down chart – line chart representing work left to do vs. time.  Helps to understand if the team will achieve its projected work goals; shows the actual and estimated amount of work to be done

Velocity chart – bar chart (per sprint) showing two grouped bars, one for commitment, and the second for completed.

6. If you have a team resistant to Agile, and are saying there are too many meetings and the process is micro managing the effort, how will you resolve this and convince them to use Agile?

Be on “their” side: “I agree, our daily standups should be all about blockers” How can we remove your blockers inhibiting your work.  “Sprint Open” is a vehicle to clarity on work to be done, and a quick turnaround time during “Sprint Close” are we delivering what the product owner is looking to achieve?  Keeps us focused on what is committed to by the team.

7.  How do you figure out the capacity of a project?

“Capacity of a project” is a ambiguous statement.  If you want to understand what can the team achieve within a given period of time, you establish (sometimes through trial and error) and verify the velocity of the team, how many points they can roughly achieve for a sprint.  Create buckets, or sprints from the backlog work, effort the user stories sprints, and an estimate is derived.  With each sprint, those estimates will be refined with a better understanding of scope and velocity.

Content from this post provided by Ian Roseman, PMP, CSM