What’s the point? Part 2 ...

Part 2 – Perception of points; views of stakeholders & the recommendation



 As discussed in part1 - "what's the point in a story point" post, product backlog is a collection of product requirements (stories, epics & themes) and delivers “value as a whole”. Scope of the product or size of the product backlog is a sum of the points of all user stories (of all sizes) in the backlog.

Completion of backlog for a release is tracked by the key metric called “release burndown”. With time/days on the x-axis and total planned story points for the release on y-axis, the burndown shows the rate at which the team is burning these story points. It’s obvious that the faster the team burns down these story points, the sooner they’ll reach the goal (release goal).

But should the focus be purely on burning points to reach the milestone?
If the team’s focus is anything but delivering value by burning points and meeting the definition of done, the product/release is on a journey that’s going to be bitter for the team. More often than not, the stakeholders (program/delivery/engagement managers, business sponsors etc.) purely look at the rate at which the team is burning story points sprint on sprint; their focus is usually on velocity and attaining a velocity which will help ensure that the release dates are met (and in turn the flow of funds is maintained).

However, does attaining a specific velocity/burning some points ensure that the team is not carrying any technical debt along and is also following xp practices (like code refactoring, continuous integration etc.)?
Technical debt, no refactoring and little/no focus on technical excellence slows down the team by adding to additional work (more than just functional requirements) that will need to be completed by the team to ensure a product that is both top class and gets business, a competitive edge in the market. Last but not the least, it also affects agility in the long run.

So how should we look at story points?
Focus on story points getting accepted and stories being pushed out to production (or at least production like environment) than just on completing stories and achieving story point/velocity targets. Team’s velocity will fluctuate over release cycles and less story points achieved in one sprint will get balanced out by more accomplished in a future sprint – at the end of the day, it’ll all average out. Teams should be motivated to deliver stories without accumulating technical debt on the run while focusing on technical excellence and delivering value.

Best,
Jasdev Singh (PMI-ACP, CSM)
https://in.linkedin.com/in/singhjasdev

Comments

Post a Comment

Popular posts from this blog

Increasing your Agile Team's Outcome Predictability

Image
Understanding Predictability in Agile Team Outcomes   "Understanding Predictability in Agile Team Outcomes" refers to the study or analysis of how consistent and reliable the results or achievements of a team practicing agile methodologies can be. This involves examining the factors that contribute to the team's ability to deliver on time and within scope, as well as identifying potential challenges or obstacles that may impact their predictability. By understanding these dynamics, organizations can better manage and optimize their agile teams for more consistent and successful outcomes. In today's rapidly changing world, the significance of accurate weather forecasts cannot be overstated. Similarly, in the world of software development, predictability is crucial for Agile teams. The ability to deliver outcomes predictably is a key factor in Agile team success. Achieving predictability can be challenging for Agile teams due to various factors such as capacity planning
Read more

Stop starting, start finishing.

Image
Limiting WIP & reasons for high WIP My first post on Kanban  deserved a sequel for sure! While it isn’t possible to have literally no work in progress, the overall goal of a project team is to finish as many things as they can, and not be in a state of continually starting. Having too much #WIP makes this goal even more difficult.  The impact of too much WIP on efficiency and throughput is one of the reasons it is often regarded as a concern. According to studies, the cost of context change is frequently far more than people anticipate. It is evident that dropping one object and taking up another cannot be done in such a way that no time or energy is spent between the two. However, there is sufficient evidence to suggest that the loss is rarely worth the gain. These apparent consequences of having too much going on are easy to identify once you know what you're looking at. Looking around the team, you'll notice that there are many tasks open, few of which are done, and many
Read more

Mastering the Daily Scrum

Image
- A Key Ingredient for Agile Success Introduction: In the fast-paced world of software development and project management, staying on top of tasks, priorities, and progress is essential. The Daily Scrum, often referred to as the Daily Standup, is a cornerstone of the Agile methodology. It's a brief, focused meeting that empowers teams to synchronize, collaborate, and make data-driven decisions. In this blog post, we'll dive into the what, why, and how of the Daily Scrum to help you harness its potential for your agile projects. What is the Daily Scrum/Daily Stand-up? The Daily Scrum is a daily ritual (a scrum event) that brings the entire team together for a brief, time-boxed catch up. Its primary objectives are: Synchronization: Ensure that everyone is on the same page regarding the sprint goal and knows what to work upon given the priority. Collaboration: Encourage open communication among team members. Identify and Remove Obstacles: Highlight any impediments that need res
Read more