The Art of getting story DONE within a sprint
Vivin Chityappa
Enterprise Agile Coach | SAFe Implementation Expert | Business Agility and Digital Transformation Consultant
List down the factors that impact story closure with a Sprint -?
?
Now let's dig deeper to see how to work with these factors to help your teams complete planned work within the given sprint timelines.
?
Velocity
The team's velocity for an iteration is equal to the sum of the story points of all the completed story points that met team's definition of done (DoD).
As the team works together over time, their average velocity (completed story points per iteration) become reliable and predictable.
Predictable velocity assists with planning and helps limit Work in Progress (WIP), as teams don't take on more stories than their historical velocity would allow.
This measure is also used to forecast how long it takes to deliver Epics, Features, Capabilities and Enablers.
?
Capacity?
Capacity is the portion of the team’s velocity that is available for any given iteration.
Vacations, training, and other events can make team members unavailable to contribute to an iteration’s goals for some portion of the iteration. This decreases the maximum potential for the team for that iteration.
For example, a team that averages 40 points delivered per iteration would adjust their maximum velocity down to 36, if a team member is on vacation for one week. Knowing this in advance, the team only commits to a maximum of 36 story points during iteration planning.
This also helps during PI planning to forecast the actual available capacity for each iteration in the PI so that the team doesn’t over commit in building their PI Objectives.
?
Starting Baseline for Estimation
In standard Scrum, each team’s story point estimating – and the resulting velocity – is a local and independent measure.
At scale, it becomes difficult to predict the story point size for larger epics and features when team velocities can vary widely.
To overcome this, SAFe teams initially calibrate a starting story point baseline for stories and velocity as follows:
Give every developer-tester on the team eight points for a two-week iteration (one point for each ideal workday, subtracting 2 days for general overhead). Subtract one point for every team member vacation day and holiday.
Find a small story that would take about a half a day to code and half-day to test and validate. Call it one Story point. Estimate every other story relative to that one.
Example: Assuming a six-person team composed of three developers, two testers, and one PO with no vacations or holidays, then the established initial velocity = 5 x 8 points = 40 points/iteration.
This way, story points get baselined and comparable across teams. Management can better understand the cost for a story point and more accurately determine the cost of an upcoming feature or epic.
领英推荐
?
Sprint Goal
This is very important, as it helps team have a common vision and stay focused on achieving the goal. The Product Owner should help the team formulate the Sprint Goal that will derive value to the product/business.
The entire team should plan -> develop -> check -> adapt on a daily basis to make sure they are on track to meet the goal by end of the sprint.
?
Scrum Team Composition
Does my team have all the skillset required to convert the business requirement to working software/shippable product.
Team must be cross-functional and ready to help each other irrespective of their specialization. A developer should be ready to help the tester complete testing. Similarly, a tester should be ready to help developers with unit testing, or listing all the scenarios that the dev needs to take care in the logic to meet the acceptance criteria.
If not, team will be blocked with bottlenecks and waiting periods to get the work completed and will not be able to close all the story within the sprint.
Scrum team should have the right mix of all the skill set required to design, develop, and test the story.
?
Definition of Done
A working checklist which must be full filled to make the story DONE.
The checklist should consider all the points that are required to consider the story potentially shippable. But also, take into account the fact that all the point in DoD should be in Scrum team’s control. If there is a dependency on an external team that would impact the DoD, then it is better to discuss/review the DoD with the team and agree on what is feasible. For example, if UAT is performed by an external team of business users, and scrum team does not have control on the testing timeline, it’s best to keep it out of the sprint DoD and add it under release DoD.
?
Environment availability and Support from System team and Shared Services
Make sure the required environments, branches, deployment pipelines are available before scrum team start development.
System team – A specialized Agile Team that assists in building and supporting the Agile development environment, typically including development and maintenance of the toolchain that supports the Continuous Delivery Pipeline. The System team may also support the integration of assets from Agile teams, perform end-to-end solution testing where necessary, and assists with development and Release on Demand.
Shared Services – Represents the specialty roles, people and services required for the success of an Agile Release Train (ART) or Release, but that cannot be dedicated full time to a scrum team.
Make sure to align the System and Share teams during PI planning.
?
Stop Starting and Start Finishing
Let’s consider a scenario where team has completed 4 of the 6 stories committed for the sprint. On the 5th story, team has completed development, but will take 2 days for testing and there is only 1 day remaining in the sprint. It’s better for the team to help QC complete testing the 5th story rather than starting coding on the 6th story. Because by the end of the sprint it’s better to have 1 story not meeting the DoD instead of 2.
Inculcate one-team mindset and eliminate silo organizational handover such as Dev to QC to Ops.