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
Summary
● 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.