top of page

The Do's and Don'ts of Agile Project Management

The other side of my life is that I am a Digital Project Manager. I have to stress the "digital" part of this title - because to be very honest, project managing software and technology has it's own specific requirements.



I thought I would share this little tid-bit with the world and what I consider the "DOs" and "DON'Ts" of running a project in Agile as a PM. This, of course, is to some degree an option that is birthed from years of experience managing everything from health care apps to holograms. Of course, the topic of Agile itself is one that is quite robust in and of itself.


I created a slide deck in SlideShare that provides an overview of the Agile process. You can check that out --> HERE.


The lists below are based on the phases within a project, some projects can be very small or these phases may not apply. That is the beauty of Agile as well; the idea of adapting in order to increase efficiency. Nothing drives me nuts more than adding in extra processes or rituals just for the sake of it. This same explanation goes for meetings, but that is worthy of another blog post I think.


DISCOVERY PHASE


In the discovery phase, we decide how to turn business requirements and features into manageable tasks for developers to understand. These features (when in planning poker) should be both prioritized and ranked in how complex they will be to complete. At this point it should be decided what features will be going into the MVP. These features are broken down into tickets/tasks that populate the backlog.


DOS

  • Do create tickets based on the features and rank them in your backlog based on priority

  • Do focus on the JIRA tickets having very specific titles that speak to the feature that is going to be built

  • Do use feature complexity and dependency as opposed to “time to complete” to organize your backlog

  • Do describe the value this will give to the user

DON’TS

  • Don’t try to create tickets that talk about implementation/technical; your dev team are the experts – keep your tickets end-user focused

  • Don’t estimate tickets on a points basis until they get pulled into a Sprint (at least that is what I have been taught)


BACKLOG GROOMING


When you backlog groom, you ensure that your backlog has the same priorities in play, priorities can change based on the overall business goals. As well, as your project becomes more mature - this can shift the context and priorities in the overall backlog. To build the backlog, the team breaks down each user story that the product owner has requested to the task level.

DOS

  • Ideally backlog grooming should take place 1x a week (the cleaner your backlog is the faster that this goes)

  • Involve your developers in the creation of specific tickets and building out the linking and dependencies in your tickets

  • Use this time to also see if there are tickets that should be injected/removed from the sprint from/to the backlog

  • If tickets are vague or the developers do not understand them, they must be beefed up at this time or rejected


DON’TS

  • Do not keep “placeholder” tickets in play in the Backlog

  • Do not have vague titles, tickets should speak to the feature that they are attempting to fulfill

  • Leave bugs in the backlog or at the bottom of a Backlog



SCRUM / STAND UP


Daily Scrum meetings help keep a team focused on what it needs to do the next day to maximize the team's ability to meet its sprint commitments. Your Scrum Master should enforce the structure of the meeting and ensure that it starts on time and finishes in 15 minutes or less.


DOS


  • Scrums should start and end at the same time every day and should be short

  • Address any blockers that may impact the work done in that day which will in turn impact the team’s ability to pass a sprint


DON’TS

  • Do not interrupt someone when they have the floor

  • Do not have a lengthy discussion: if there are topics that need to be discussed further they should be placed in a “ virtual parking lot”


SPRINTS



Much of sprint planning involves a negotiation between the product owner (the project manager can act as the proxy) and the team to determine the focus and work to tackle in the upcoming sprint. Sprints involve a commitment of the team to the work that will be done within that sprint, whereas the Backlog forecasts the upcoming work.


DOS


  • Ensure that your backlog is groomed in priority sequence to ensure that planning does not end up wasting time

  • Have each team member commit to the work that they will complete within that sprint - each team member should have clear marching orders on what is expected of them during the time of the sprint



DON’TS

  • Don’t “fill your sprint to the top”; you need to leave room for emergent tasks

  • Don’t start a sprint without every task being estimated and understood

  • Don’t let the product owner influence technical implementation of a user story


SPRINT END


Sprint end is more than just simply the end of the 2 week period (of however long it has been decided to create a sprint). There are two aspects: i) Sprint Review and ii) Retrospective. Sprint Review is much more client/business centric. Sprint Review is about communicating to stakeholders about what was done that sprint.


DOS


  • Ensure that your backlog is groomed in priority sequence to ensure that planning does not end up wasting time

  • Have each team member commit to the work that they will complete within that sprint - each team member should have clear marching orders on what is expected of them during the time of the sprint



DON’TS

  • Don’t “fill your sprint to the top”; you need to leave room for emergent tasks

  • Don’t start a sprint without every task being estimated and understood

  • Don’t let the product owner influence technical implementation of a user story




bottom of page