Agile estimates using Pega 7
The below is an email conversation between our Scrum Masters and Janani Liyanage from Virtusa (Janani has permitted me to share the conversation). We thought the conversation would be useful for other aspiring Agilists, so we're posting the conversation below. Feel free to comment or ask questions.
Hi, Please share me how do Pega scrum projects size the user stories. What is the scale. Suppose if they are using Fibonacci or T-shirt size for story point. what size parameters differentiate from story point 1 to 3 to 5 or small , medium to large. In other technologies like Java, .Net we use complexity and risk to size the user stories such as number of interfaces, integration points, functions to differentiate sizes. How do we perform this in Pega.
For the most part, teams using Pega 7 don’t size their stories any differently than teams executing any other type of work (which includes work outside the realm of software development). The typical process looks like this:
- A brand new team will write/groom/refine a handful of stories, and the team will order the stories by size/complexity/difficulty in relation to each other (this is before assigning any sort of point value to any of the stories).
- Then, the team will assign a point value to the smallest/least complex/easiest story (typically this will be a 1, 2, or 3).
- Then, the other stories will be assigned point values based on how many times bigger the stories are than the smallest story, while sticking to the Fibonacci sequence. For example, if the smallest story was assigned a 2, and the next story is roughly 4 times harder, then that story is assigned an 8. If a story is roughly twice as hard as the first story, then the story will be assigned either a 3 or 5 (it’s up to the team which number is more appropriate based on the team's understanding of the story).
- Once the team’s initial stories are sized, the stories will be the reference stories for all future sizes. Teams will write/groom/refine a new story, and they will compare that story’s complexity to that of the reference stories. Whichever reference story is closest to the new story is the reference story whose size the team will use for the new story.
You mentioned a few conversation points that your previous teams used to help them size stories (number of interfaces, integration points, functions, etc.). Some Pega 7 teams will determine similar conversation points that they always cover before sizing a story (things like number of rules, is custom java needed, how many new case types, etc.), but for the most part we don’t think it’s needed if relative sizing is done correctly (as described above). Nonetheless, we don’t think the conversation points hurt a team’s ability to size. The sizing conversations simply might last longer than needed.
Does this help?
Thank you so much for the insights
This is extremely useful