What does Sizing mean at Pega?
What is the meaning of 1 story Point at Pega? I have known different teams to do it differently. Some consider 1 Point to be a day. Some follow the classical Scrum thought process of picking us a baseline user story as a 1 pointer and do relative sizing for other stories. What is the suggested practice at Pega? Should we just use 1 point as 1 day because it helps in planning, with the risk of ignoring the aspects of complexity and uncertainty?
DLL Finance LLC
US
My scrum team is currently working almost exclusively in Pega.
I'd start by saying that, if you search the Scrum guide, you won't find the word "story" anywhere. The idea of a user story isn't something that comes from Scrum, so therefore neither does a story point.
In my opinion, the key thought from the Scrum guides that relates to this question is this: "No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality." We believe strongly that the team does whatever works for them. My team, for instance, uses relative complexity as a sizing tool. The number of points does NOT correlate to the number of hours of work needed to complete it. We also do not use velocity as a metric that gets reported to stakeholders - it's only for team planning purposes. As we've been through many sprints now, we have a rough idea of the average points we can complete in an increment. That’s really all it’s good for to us.
The answer to your question of “should we use…” then is, you should use whatever works for you. Try something, see if it works. If it doesn’t work, try something different. If it works, see what you can do to improve it.
Hope that helps!
Accepted Solution
Pegasystems Inc.
US
Hi folks!
I'm on board with with @PeterC14's observation that neither stories nor points are native to Scrum; and more importantly: the team decides!.
While there is no absolute right or wrong answer in terms of what defines story pointing, the consensus in the agile world is that:
- They reflect time, complexity, and risk
- Are relative in size - for the specific team - in comparison to other units of work (stories) delivered by that team
- Are essentially 'unitless'. Some teams use T-Shirt sizing (S, M, L, XL, XXL)
In Scrum, the only other thing to add is that the collection of stories in the Sprint Backlog must be sized such that the team can meet the commitment.
Hi folks!
I'm on board with with @PeterC14's observation that neither stories nor points are native to Scrum; and more importantly: the team decides!.
While there is no absolute right or wrong answer in terms of what defines story pointing, the consensus in the agile world is that:
- They reflect time, complexity, and risk
- Are relative in size - for the specific team - in comparison to other units of work (stories) delivered by that team
- Are essentially 'unitless'. Some teams use T-Shirt sizing (S, M, L, XL, XXL)
In Scrum, the only other thing to add is that the collection of stories in the Sprint Backlog must be sized such that the team can meet the commitment.
I'll add a +1 on the comment that velocity "is only for team planning purposes". The reality is that many organizations will try to see velocity as a metric for managing releases. Predictability can be determined for a given team using velocity. An analogy would be planning a trip using an average speed of 60 miles per hour. If your destination is 240 miles away, you'll predict that it should take 4 hours. Similarly, a team with a velocity of 15 points per 2-week sprint, will likely finish 60 story points in 4 sprints. This model starts to break down however, when multiple teams are involved, particularly if they're using different story point scales (e.g. a 5 for Team A is roughly an 8 for Team B). There are other potential options for predictability "metrics", but that's probably a different post...
Cheers!