Agile Program Management  Primer

Why Agile? 

It is a project / program management methodology that is a great fit for complex software dev programs that would defy a complete up-front  definition, where we expect variability and rely on frequent, early feedback 

  • It makes use of Progressive Elaboration 

● Helps us Reduce Risk by providing transparency.  

● Face-to-Face interactions are fostered 

● Ongoing progress is shared honestly and frequently.  

● Welcomes changing requirements 

● Based on self-organizing teams

Even though we can’t define all of the program details far in advance, there are some things we need to spend time and effort to define well early on.

Product Vision Statement – Product Goal

it describes in a few sentences the product’s purpose: 

● Who is it for 

● How it is in keeping with our organization’s objectives

● The benefits we will extract from successful deployment

● The consequences if we fail 

● It is to be created and presented by the Product Owner

● It is a key for motivating the team. 

● It is shared so everyone buys in 

● It is broad and engaging, but concise.  

● It leaves room for trade-offs

Product Vision Statement Example 


For Example:

For network engineers who  want to obtain device  diagnostics data and update  vendor service requests  programmatically, autodiag  tool will save time and  manual toil.

Agile methodology uses a number of structure to define the work that needs to be done. These structures should ideally follow a pre-defined format that provides the necessary level of details, allows for completeness and yet leaves room for dialogue within the team, which is huge key of the agile process. See details of these structures below:

For (target customer) who (statement of need or opportunity), the (product name) is a (product category) that  (key benefit) 

User Story = Specific Functionality from user  perspective that fits in a single sprint

Theme: Top-level objectives can also be defined as a big chunk of work that has one common objective. It could be a feature, customer request or business requirement. 

Epic: a large story – often defined as one that is too  big to fit in a sprint 

User Story: a requirement written from an end user’s  perspective 

Now that we have a clear understanding of what we are building, it’s time to put together some outlines of how we going to deliver on our vision. What are the milestones we need to get through in order to realize our product / project goals. This is where the concept of product roadmap comes into play.

Product Roadmap 

● It is a high-level chronological depiction of how the  product owner will bring a product to market. 

● Typically done once or twice a year 

● Created and maintained by Product Owner – T/PgM and or TL. Creation of the Road Map involves input from multiple  Stakeholders but TL along with T/PgRM assigned to the  program are the main voices. 

● Allows business level stakeholders and dev team to  communicate around high-level themes.

● Dev Team should have a good understanding of the Roadmap  so that high level architecture plans can be aligned and  new learning and skill sets that may be needed can be  acquired. 

● Vision and Roadmap Leads to Product Backlog 

  • The product or release backlog is a list of features,  requirements, and bugs for the product, prioritized by  value (top to bottom). 

● List of deliverables written from business  point of view to be done in order to achieve  a desired end state. 

  • These items can be planning, analysis,  architecture, design, coding, unit  test, documentation, functional tests  and bug fixes, system test, user  acceptance, pilot, etc 

● Prioritized based on value, risk, cost /  benefit, etc 

● More detail is provided for higher priority  items that are higher on the list 

● TL along with T/PgRM is responsible for  managing this list but anyone can contribute  to it. 

● Should be shared with everyone and kept  up-to-date

  • High priority features are always  implemented first 

  • Any new requests get prioritized within  an existing stack 

● Non-started features’ priorities may  change 

● Features can be removed at any time.

● Items at the top are more detailed  and concise than the items lower on the  stack. 

● The priority should be given to items  that will allow us to show our stakeholders what we are doing so we can  get early and frequent feedback. 

● Product backlog should be constantly  refined and groomed (done by TL along  with T/PgRM)

Type of Product Backlog Items (PBIs)

How to come up with a Product Backlog 

● Brainstorm and prioritize the epics in order

● Go through the epics in order and break each down into a  stories which can be completed within a single sprint

● Prioritize the stories within each Epic. 

● Identify critical stories within each epic from technical  and business perspective 

● Move critical stories up (we still maintain which epic  each story belongs to) 

● PBIs will be later placed into sprints.

User Stories 

● It is a requirement written by a user or from a user’s perspective

● User stories are to be discussed within the team 

● Each story should be adding value to our customers / stakeholders

● Should be sized for the sprint (small) -> fit within single sprint.

● Should be testable 

● Should include acceptance / success criteria (DoD) 

  • PBIs don’t have to be written as user stories but it is helpful.

Let’s look at an example:

“As Network engineer I want to be able to see if a given  configuration push is causing issues within a specific location  so I can make informed decisions about whether or not a  configuration push should be paused”

Story Point Estimating 

● The story level estimating is done in story points – not  as a unit of time but relative to other stories. ○ We can use Fibonacci series 1, 1, 2, 3, 5, 8, …..

  • If all Dev Team members pick close to the same  estimate it stays 
  • If estimates are widely different, the difference is  discussed and the vote is repeated in order to get  closer to a consensus. 

● As the team gains experience, estimating becomes easier since we can make comparisons with the stories /  deliverables we have already estimated / scoped and  completed in the past.

Story Point Estimating Example 

Let’s say we have 3 technical user stories:  

1) Build a module that would detect a failed FPC on the device that needs to  be reloaded. 

2) Build a decision engine that determines which commands need to be executed  based on the issue and device type 

3) Build Execute FPC reload module 

Dev Team can make estimates based on complexity involved in implementing the  functionality associated with these stories: 3 story points to deliverable #1  5 story points to #2 and 2 story points to #3 

If all 3 stories were part of our sprint we would have a 10 story point  sprint.

Sprint Planning 

● During sprint planning the dev team pulls the items from the top  of the product backlog. (plan to schedule at least 1 hour for your planning meeting) 

● This will determine what the team will be working on during the next sprint which typically takes between 1 to 3 weeks (I find 3  weeks a little easier to manage due to team’s on-call rotation  availability) 

● Here we can also take into account team’s productive work hours, which would exclude time for meetings, sick days, on-call  rotation etc. (20 hrs per engineer per week sound reasonable,  but may vary depending on the level availability of the  engineers on our dev team)

Tasks Level Breakdown 

● Starting with the first item in the sprint backlog the Dev Team breaks it down  into tasks that need to be done (design, coding, unit testing, functional  testing, code review, etc) 

● Dev Team estimates amount of work hours each task would take (ideally a task  should be 8 hours of work or less, but this level of breakdown isn’t always  possible, but it’s great if we can) 

● Dev Team sign themselves up for work on the tasks identified for each sprint  backlog item (in our case this would end up being a set of buganizer bugs).

● At this point total amount of hours to complete all tasks is added. If this  amount exceeds team’s capacity, we know that some of the items should be  removed from this sprint’s commitment (we should avoid overcommitting and have  tasks that aren’t 100% done to go into the next sprint)

What is Sprint 

● Sprint is a timebox in which team is committed to deliver some amount of work. ○ The team is committed to delivering just functionality they are able to  complete 100% including all unit / integration / functional testing  required with a focus on quality at a sustainable pace. 

● The team picks the most high priority / high value work from the product  backlog that is decomposed into tasks that team members assign to themselves  and commit to completing 

● This timeboxed approach helps the team and outside stakeholders know exactly  what will be delivered during specified period of time (sprint duration)

● Important!!! Sprint goals / scope should not fundamentally change during the  sprint (with few exceptions), but clarifying the details of the scope is still  valuable as we discover additional details during sprint.

Sprint Execution 

● On a daily basis Dev team works on the tasks in the sprint  backlog 

● Updating the chart or kanban board let’s the team show all  the stories and their associated task states within a given  sprint

Daily Standup Meetings 

● The daily Scrum is a time for the self-organizing Development Team to share status,  plans and any impediments. The daily stand-up meeting is typicallly 15 min long, where  we conduct a round-robin Q and A 

  • What was accomplished since last standup 
  • What do you plan to accomplish by next standup 
  • Any blockers 

■ It will be the job of T/PgM to go after this impediments on a daily basis to  unblock the team members. 

■ Standup is not the time for problem solving, that can be done offline. ● T/PgM / TL and Dev Team attendance is generally very desirable, but experienced agile  teams can run their own meetings as well. 

● The daily Scrum is essential to the ongoing success of any sprint. It keeps the  Development Team focused on deliverables and reinforces commitments to their fellow  team members 

● The daily Scrum should not be canceled, even if only a few team members can attend on  a given day

Sprint Outcome 

● The product increment is the sum of all backlog items  completed during the current sprint 

● Potentially shippable is defined by a state of confidence or  readiness, and shipping is a business decision 

● Shipping may or may not occur at the end of the sprint ● Often, new functionality is accumulated via multiple sprints  before shipping a given feature or functionality. ● Demos to the stakeholders during sprint reviews can be  tremendously valuable as a way to get early and continuous  feedback on the functionality we’ve delivered and planning  to deliver during the next iteration

Sprint Retrospective 

● This is private meeting with no external stakeholders

● Scrum Master and Development Team inspect the performance of the  preceding sprint and identify what went well, what didn’t go well,  and improvements to be implemented during the next sprint.

● It is done after Sprint Review meeting. 

● Points to be addressed during these meeting are below ○ What we did well 

  • What we can improve 
  • Skill sets, velocity improvements, etc 
  • Discuss Definition of Done for the stories


● The product vision statement is created 

● The combination product roadmap and release plan is established

● The team is formed 

● The product release backlog is developed, and items were estimated in story points  and prioritized 

● The sprint goal was established, and the Development Team committed to what would  be completed in the sprint 

● The Development Team determined how to complete the work, and the sprint backlog  is produced 

● Sprint execution encompasses the work of the Development Team and supporting activities and artifacts—the daily standup, task board, any blocking bugs and most importantly, a potentially shippable product increment produced by the team. 

● The sprint review is the venue for live demonstrations of the done functionality

● The sprint retrospective facilitated the identification of one or more action  items supporting continuous improvement

Hope this was a helpful overview. It is meant to be a very brief summary of agile program management process. Please do not hesitate to ask any questions.

Published by Yev

Happy to meet you all. I am a Technical Program Manager who is passionate about learning, teaching and mentoring.

Leave a Reply

%d bloggers like this: