Agile planning

Software development should be planned and tracked.

Your teammates want to know what you’re working on so they can collaborate with you effectively.
Teams need to track progress so they can plan future work and course-correct as new information is discovered during development.
Without a deliberate process, projects drag on, outside demands steal focus, and operational issues distract developers.

Agile development, a software development methodology, is widely adopted to deliver quality software quickly and it serves as a perfect tool to achieve above mentioned objectives. The Agile Manifesto states the main principles of Agile methodology

The Agile Manifesto (2001)

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Agile is usually contrasted with Waterfall, an out-of-fashion practice where projects get exhaustively planned at their inception. As a methodology, Agile needs a framework to get executed within it.

Agile Planning Frameworks

Scrum and Kanban are the two most common Agile planning frameworks.

Scrum, the most popular, encourages short iterations with frequent checkpoints to adjust plans.

Development work is broken into sprints. Sprint length varies, with two weeks being most common.
At the beginning of a sprint, each team has a sprint planning meeting to divvy up work, which is captured in user stories or tasks.
After planning, developers start on their work. Progress is tracked in a ticketing or issue system.
A brief stand-up meeting takes place every day to share updates and call out problems.
After each sprint, teams perform a retrospective to review finished work, discuss new findings, look at key metrics, and fine-tune the process. Retrospectives(retros) inform the next sprint’s planning session, creating a feedback cycle from plan to development to retrospective and back to plan.

Kanban does not use fixed-length sprints like Scrum. Instead, Kanban defines workflow stages through which all work items transition (for example, backlog, planning, implementation, testing, deployment, roll-out).

Kanban limits work in progress (WIP) by limiting the number of tasks in each stage.
By limiting ticket count, teams are forced to finish existing tasks before taking on new work.
Kanban boards are dashboards with vertical columns for each workflow stage.
Tasks, represented by titled boxes, are moved between columns as status changes.
Kanban works best for teams like support engineers and SREs that handle a large number of incoming requests rather than longer-term projects.

Teams rarely implement the “platonic ideal” of Scrum or Kanban; they pick and choose some practices and alter or ignore others. Whether your organization practices Scrum, Kanban, a mashup of the two called Scrumban (that’s a real thing!), or some other variant of Agile, the planning process should be in service of delivering useful software to happy customers.

Scrum

Lets look at Scrum framework in detail here.

All planning usually begins with prework.

Developers and product managers create new user stories, and tickets from the backlog are triaged.
Stories are assigned story points to estimate their complexity and are broken into tasks.
Larger stories are designed and researched with spike stories. (For which usually design docs get created)
During sprint planning, the team chooses which stories to complete during the next sprint, using story points to prevent overcommitting.

User Stories:

A user story is a specific kind of ticket that defines a feature request from a user’s perspective, in the format “As a <user>, I <want to> <so that>.”
A common misuse of user stories is to jam a regular task description into a story, as in “As a developer, I need to upgrade the shader plugin to version 8.7”
Stories usually have attributes beside their title and description. The two most common are estimates and acceptance criteria.
User story estimates are a guess at the effort a story takes to implement.
Acceptance criteria define when a story is complete. Acceptance criteria keep developers, product managers, QA, and users on the same page. Try to write explicit tests for each acceptance criteria.
Small stories often double as work tickets, while larger stories are linked to implementation tickets or subtasks.
Stories that are ambiguous or need design are spiked. A spike is a time-bounded investigation that enables other stories to be completed. Spikes deliver a design doc, a build-versus-buy decision, an assessment of trade-offs, and so on.

Tasks: A good trick for breaking down work is to write very detailed descriptions.

Story Points:

The team’s work capacity is measured in story points, an agreed-upon sizing unit (measured in hours, days, or “complexity”).
A sprint’s capacity is the number of developers multiplied by the story points per developer; for example, a team with 4 engineers and 10 points per engineer would have a 40-point capacity.
User-story time estimates are also defined in story points;
the sum of all story points in a sprint should not be greater than a sprint’s capacity.
Many teams use time-based allocations where a single point amounts to one workday. Day-based estimates usually account for nontask work— meetings, interruptions, code reviews, and so on—by defining a workday as four hours long.
Others define story points by task complexity, using a T-shirt size approach
Agile framework doctrine frowns upon time-based estimations. Practitioners claim that dates have emotional attachment and don’t represent complexity.
Estimating story points is subjective; people tend to be poor estimators. One way to improve estimation accuracy is to use relative sizing to derive the values. Relative sizing is done by defining story points for tasks that have already been finished and then comparing the finished task to one that hasn’t yet been worked on. If the unfinished task is less work, then it’s probably fewer points; more work is probably more points; and if the tasks are similar, then they should be assigned the same value. Processes like planning poker are sometimes used, but even if you don’t take part in them, looking at finished work will give you a feel for your team’s story point values.

Backlog Triage:

Backlog triage or grooming (in the tree-trimming sense) usually takes place before planning meetings.
The backlog is a list of candidate stories. Triage is used to keep it fresh, relevant, and prioritized.
Product managers read over the backlog with the engineering manager and sometimes with the developers.
New stories are added, outdated stories are closed, incomplete stories are updated, and high-priority work is moved to the top of the backlog.
A well-groomed backlog will drive planning meeting discussions.

Sprint Planning:

A sprint planning meeting is held once prework is done.
Planning meetings are collaborative; engineering teams work with product managers to decide what to work on.
Prioritized stories are discussed, and engineers work with product managers to determine what will fit into the sprint’s capacity.
Each sprint capacity is further refined during sprint planning as team members join or leave, go on vacation, or enter or exit on-call rotations.
The most important feature of a sprint is that it’s short—usually two weeks.
Sprints are considered locked once sprint planning is done.
New work that surfaces during the sprint should not be pulled in; it should be pushed to the backlog and planned for a future sprint.
When unplanned work does get pulled in, the team is expected to look into the reasons during the retrospective, with an eye to reducing unplanned work in the future.
Strict adherence to sprint planning practices is uncommon.

Stand-ups:

After sprint planning is complete, work begins, and the team holds stand-up meetings, also called scrum meetings or huddles.
Stand-ups are usually 15-minute meetings scheduled every morning.
In the meeting format, teammates go around a circle and give an update on what they have worked on since the last stand-up, what they plan to work on going forward, and whether they’ve found any issues that can delay or derail the sprint.
Stand-ups are a regular system check—the glance at your car’s dash- board to ensure that you have gas and that its mysterious “check engine” light is not on. Updates should be fast; they are not a place for trouble- shooting.
Discussion about your discoveries can then happen in the parking lot (not the literal parking lot, of course). Parking lot discussions happen after the meeting. It’s a way to keep the stand-ups brief and make sure that the discussions are relevant to everyone attending. When someone says to “save it for the parking lot,” they’re saying to stop the discussion and pick it up after the stand-up with interested parties.
If your team holds synchronous stand-ups, do your best to be on time.
Skipping the meeting when scheduling conflicts arise is acceptable. Ask your manager how to provide and get updates if you need to miss a stand-up.
Asynchronous stand-ups are skipped less often.

Reviews:

A review happens between each sprint. Reviews are usually broken into two parts: demonstrations and project review.
It’s standard to keep reviews to no more than one hour per sprint week—a two-week sprint would have a two-hour sprint review.
Reviews celebrate team wins, create unity, give feedback opportunities, and keep teams honest about progress.

Retrospectives:

One of the 12 principles in the Agile Manifesto says, “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” Retrospective meetings address this principle.
In a retrospective, a team gets together to talk about what has and hasn’t gone well since the last retrospective. The meeting normally has three phases: sharing, prioritization, and problem solving.
The leader (or scrum master) will kick off a retrospective by asking everyone to share what worked and what didn’t during the last sprint. Everyone participates, and the scrum master keeps a list on the white- board or in a shared document.
Finally, the team brainstorms ways to address the highest priority problems.
Retrospectives normally take place between sprints, often right after review meetings.
Many teams combine a review, a retrospective, and a sprint planning meeting into a single meeting at the beginning of each sprint. A combined meeting is fine as long as each step—review, retro, and planning—is discretely addressed.

Roadmaps

Managers use product roadmaps for long-term planning. Roadmaps are typically broken into quarters: January through March, April through June, July through September, and October through December.

Planning takes place before each quarter begins. Engineering managers, product managers, engineers, and other stakeholders all convene to discuss upcoming goals and work. Planning usually involves a series of meetings and multiple rounds of discussion.

According to The Papers of Dwight David Eisenhower, Volume XI, Eisenhower said, “In preparing for battle I have always found that plans are useless, but planning is indispensable” (Johns Hopkins University Press, 1984). This applies to roadmaps. We’ve never seen a yearly or even quarterly roadmap be 100 percent accurate; this isn’t the point.

Quarters that are farther away should be fuzzier, while quarters that are closer should be more accurate. Don’t fool yourself into thinking any quarter is 100 percent accurate.

Unlike sprints, which are locked, roadmaps are meant to evolve. Customer requirements will change, and new technical problems will arise. This is where sprint planning, reviews, and retrospectives help; they let you adjust your plan based on new information. Communication is critical when changing roadmaps. Dependent teams should be notified early that work is getting shuffled or dropped.

Yearly planning is mostly theater—horse- trading and negotiating. Nonetheless, yearly planning cycles often drive “resource allocation” or “head count numbers”—corporate speak for where newly hired engineers end up.

Note

Sources:

https://www.atlassian.com/agile