Estimating 1 story point for all tickets <=3 days work.

Hi Joseph,

There are many ways of sizing work, and ultimately the best choice is going to be the way that works best for the team. If the team can collaborate and agree on what makes a backlog item a 1, then I believe this is a good thing. The conversation and alignment is the major value add for sizing and it seems they have that sorted.

Teams could use t-shirt sizes, numbers, letters, Simpson's characters or nothing at all. 

Some teams use NFC, 1, TFB (No Flipping Clue, 1, Too Flipping Big) - the f-word may be different :)

Can you elaborate on what transparency and openness would be missing with this approach?

Sizing is done at the Product Backlog item level, which includes anything needed to turn that PBI into a working increment of value. Rather than viewing as "dev ticket estimating", consider as Developers working together to size. 

Within a Scrum Team, there are no sub-teams or hierarchies

On the surface, I don't see any inherent problems with what the team is describing. Depending on the length of the Sprint, three days could be a long time and the team may want to consider breaking work into units that could be completed in less time, perhaps a day or two at most. The maximum size of a unit of work is very contextual and there's no one-size-fits-all approach to how big a unit of work should be.

The workflow definition is of more interest to me. A simple workflow of "to do"->"doing"->"done" isn't very transparent for most types of work. Defining and visualizing a more robust workflow on the board would help increase transparency and turn your board into an information radiator for stakeholders. Taking the time to talk through the workflow and making it visible is a good first step. It also opens the door to making metrics like work item aging, or how long a work item has been either in progress or in a particular state, more useful. Work item aging, with cycle time, can start to give the team good discussion points at the Daily Scrum. Flow metrics in general can help enhance Sprint Planning and Sprint Review, as well.

The exercise of defining your workflow will also answer your question about testing as part of estimation and planning. If testing is part of your team's workflow, then it should be considered during any estimation activities and would become visible as work moves through the workflow. I would suspect that most teams do some amount of testing, even if there's further testing downstream and outside of the team's workflow.

I just joined a team and the developers have decided to just have 1 story point for every ticket on the condition that any ticket they work on should not be more than 3 days. Any ticket that they believe will be more than 3 days work must be broken down further. In my opinion, I feel this will not enhance transparency and openness on our Jira board as everyone in the organisation will see just 1 story point for even tickets that will take  3 days to be completed.

Why would the organization even care to look, as long as the Developers are meeting their Sprint Goal commitments and Done increments of immediately usable work are being delivered?

Furthermore it defeats the empirical process control where tickets that are to move from one swim lane to the other are not easily identified for inspection and adaptation among other concerns. 

That's interesting. Can you explain a bit more about how these smaller pieces of work compromise transparency?

On a separate note, I also want to find out if testing should be part of dev ticket estimating in the planning session for my own understanding and learning. 

I'd suggest that if testing wasn't included, then transparency would be reduced, since it will be unclear how much work remains to be Done.

@Ryan @Ian and @Thomas, thank you for your feedback, with respect my transparency concern, the story point of 1 will be shown for all the tickets, my thought of transparency is to show estimated story point as a 1, 2 or 3 on the board rather than just 1 even for task that will take 3 days, just like in T Shirt sizing, we could have S ->XXL, all task should not be sized as S when the dev is aware that some of those S are actually XL or XXL (compromise of openness/transparency in my opinion) subject to been corrected as I am on a learning journey. 

I was also looking at it from the workflow perspective which @Thomas have addressed very well. @Ian, the organisation I was referring too will be reframed as the stakeholders but your point that if the Sprint Goal is met and Done Increment is usable why will they care has been taken on board. 

What is wrong with "point of 1 shown" for PBIs? 

Your team has a working agreement to focus on having small backlog items that they forecast could be done in a 3 days or less. The 1 to them just means it qualifies. You could use no estimates at all here and that would be fine too. The key for them is that they have refined and broken down PBIs into a size that is acceptable for them. If measurement is a concern, you can measure throughput instead of velocity and use number of PBIs instead of points when thinking about capacity at Sprint Planning.

Consider that how long it will actually take to turn a PBI into value is really unknown. No amount of granularity in sizing will make that known. It really is a guess. Complex problems mean more is unknown than known, and the team won't know until they get into the work. Time spent focusing on trying to be more precise is likely to result in waste. The reality is that even something that is considered to be a Small could end up taking 3 days (or more).

Over the past few years I have been conducting analysis of story points (forecast) vs. cycle time (actual time) across a dozen or so products in my current organization. Regardless of the team, I see the same pattern. It doesn't really matter if something is estimated at 1 point, 2 points, or 5 points. The actual differences in cycle time are minor. Backlog items that have been pointed as 1 could take longer than items pointed at 5 and items pointed at 5 could be done in the same time as items pointed as 1. Allen Holub posted examples on twitter a few years back to illustrate what this reporting looks like: https://twitter.com/allenholub/status/1362840033502191616/photo/1

At the end of the day, @Ian's quote calls out what is important. Meeting Sprint Goal commitments and delivering Done increments of value...

Why would the organization even care to look, as long as the Developers are meeting their Sprint Goal commitments and Done increments of immediately usable work are being delivered?

If stakeholders are focusing on story points, they are looking in the wrong spot.

with respect my transparency concern, the story point of 1 will be shown for all the tickets, my thought of transparency is to show estimated story point as a 1, 2 or 3 on the board rather than just 1 even for task that will take 3 days, just like in T Shirt sizing, we could have S ->XXL, all task should not be sized as S when the dev is aware that some of those S are actually XL or XXL (compromise of openness/transparency in my opinion) subject to been corrected as I am on a learning journey. 

Transparency is not related to the size of something.  It is achieved by sharing information about what, how and why things are done.  If this team has shared with everyone that 1 Story Point represents 3 or less days of work, then they are being transparent.  Your example of T-shirt sizing doesn't take into account that the sharing of information on the sizing method could be that a small is 3 or less days of work.  Just like the current 1 Story Point. 

Like everyone else has said, if that method works for the team and they are consistently delivering usable increments of value, why question the methodology? 

Workflow in your information radiator will show more information than estimates.  That will allow individuals to see the state of the work with a quick glance.  An estimate alone will require that individuals have to ask for a state of work.  Your efforts would be better served helping the Developers understand what kind of information outsiders might want to know from the information radiator and coach them on how to provide that.  How does the team know what outsiders would like to know?  The team asks them.  

On a separate note, I also want to find out if testing should be part of dev ticket estimating in the planning session for my own understanding and learning.

Is testing something that has to be done before a usable iteration of value can be delivered?  In my opinion, the answer to that is always "yes".  Even if it is being delivered to a separate QA team, there should still be some testing carried out by the Developers before doing the delivery.  So.... Absolutely yes, the testing should be part of Developer estimation.