Estimation: dev & QA - help

Can a PBI meet the Definition of Done and be releasable without testing?

All parts are important. There shouldn't be any trumping of anything here or any lesser than, greater than dynamic.

Sizing isn't about individual effort. Rather than breaking into parts consider what is needed, holistically, to turn PBI into usable increment and size accordingly. Story Points are just relative values being applied and you can work within the scale established by the team. Precision isn't the name of the game, collaboration and conversation is. 

Beyond sizing, there is another issue to explore in terms of inner-team division. In Scrum the accountability of Developers encompasses all skills needed to turn product backlog items into usable increments of value. Skills such as coding, testing, design, integration etc. all fall within this. If you are contributing to this, you are a Developer in a Scrum Team.

Right now you don't appear to have a team, because they're shying away from teamwork. You have a workgroup of skill silos. Presumably this will matter when it comes to making a joint commitment.

It will also presumably matter to the Product Owner. How could he or she reasonably determine the value of a so-called "dev story" or "QA story"? The PO owns the Product Backlog, and ultimately has the say on what goes on it.

The Developers, who incorporate QA and all other skills required for Done work, need to collaborate effectively. Those who are unable to collaborate when estimating work are unlikely to do so once a commitment on doing that work is made.

Good responses from @Ryan and @Ian.  

I have a questions.  Do your developers write unit, integration, or system level automated tests?  Aren't those part of the Quality Assurance effort for the product?  Would that effort be split out of the Development effort estimate and included in the QA portion? If you split the item into Dev and QA items, would the Dev item be done before QA had a chance to perform their testing? What if an issue is found by a QA test? Would that become a new item that had to be dealt with later which would mean incurring technical debt? Or would it be addressed by the Developers in the same Sprint? If the latter, does that mean the Dev item is reopened because it was not completed satisfactorily? 

I hope this helps you to see the issue with splitting the items by discipline.  It would be the same as splitting a dev item between front end and back end.  At some point, you are no longer capturing items of value in your backlog, you are turning it into a task list.

Story points are an estimate made at a point in time using the information you have at that point in time.  The only benefit they provide is for the Developers (coders, testers, designers, integrators, documenters, etc) to determine if they feel the body of work they select for a Sprint Backlog can be addressed to satisfy the Definition of Done during the Sprint timebox. And as soon as work begins, there will be new information obtained that could invalidate the original estimate.  So once a Sprint begins, those estimates are worthless.  

Now, having said all of that, it is really up to the Developers (coders, testers, designers, integrators, documenters, etc) to decide how they want to use Story Points and what they mean. Because their meaning is only relevant to that specific group. If they feel splitting the estimate by discipline and then putting them through some kind of mathematic formula is useful to them, who am I or you to say they are wrong? You, as a Scrum Master, have the responsibility to make sure that everyone, inside and outside the team, really understand the use of Story Points and the dangers of trying to use them for purposes outside of their intended purpose. I suggest you read and share this with others. It is an article written by Ron Jeffries, who is said to have created Story Points.  It should help people understand the benefit and pitfalls. 

I believe the Developers' skills distribution is an important factor the team needs to consider when sizing the PBIs. Let's say there is only one person on the team with specific mathematical knowledge required for creating an algorithm necessary for certain PBI. That thing alone would make this PBI of a significant size for the team. The teamwork might be excellent on that team but nobody besides the mathematician will be able to create the algorithm.  

If the product requires various niche skills sizing with only one measure might not be sufficient for effective forecasting and Sprint Planning. The Scrum Guide doesn't say anything about how the sizing should be done. The only thing it says is that it must be done by the Developers. The Scrum Master is there to help the developers to find a good technique.

Thanks for the replies everyone - these really help! I'm now better equipped to have these chats :)