On Aug 29, 2016 3:04 PM, AB [firstname.lastname@example.org] wrote:
Can I run this by you?…
When QA is a part of the DEV sprint, and they help to write test cases etc. Do they add in story points?
There is a bit of an issue with reporting. The story points are assigned for dev code review tasks, dev functional testing, now QA test cases writing (since they’re in the same sprint), and other activities done by DEV.
Then when we run reports based on story points, it is not really a good reflection of how much development work is done, because of all these other “tasks”. Am I looking at this wrong since everything needs visibility, or should we be more strict about what gets assigned story points?
On Aug 29, 2016 4:44 PM Joseph Flahiff, Whitewater Projects, Inc <email@example.com> wrote
For story points to work best, there is no dev/test split. There are only people who make software.
So, if you back away from that pure mode you need to acknowledge and compensate for the compromise you are making. It will cause more complexity and reduce accuracy.
On Thu, Sep 1, 2016 at 3:55 PM AB [firstname.lastname@example.org] wrote;
Thanks. btw, what is the best way to track a ticket that will take multiple sprints to complete? Adding a part 2 ticket seems to be overkill.
On Sep 1, 2016 4:05 PM Joseph Flahiff, Whitewater Projects, Inc <email@example.com> wrote:
Best way is to break it into pieces that can be completed in one sprint 😉
Ok. The other way is just to carry it over from sprint to sprint. What tool are you using? in some tools you can split at the sprint mark and carry over only the work that is expected to continue. This is suboptimal. Again you will need to acknowledge the compromise and accept the risk it creates.
On Thu, Sep 1, 2016 at 4:56 PM AB [firstname.lastname@example.org] wrote;
For people who are reporting against the tickets, it is confusing to have so many tickets for one feature, that’s where the resistance is. Maybe we can try carrying it over and see. We use [agile tracking software].
On Thu, Sep 1, 2016 at 5:20 PM, Joseph Flahiff, Whitewater Projects, Inc <email@example.com> wrote:
A few questions.
Who is making the story cards? Are they story cards or are they technical specifications? I would love to see an example.
Back to the QA/DEV question. You might want to try an experiment. add a column to your board for QA. so it would go READY / DEV / QA / DONE. Add exit criteria for items going from DEV to QA e.g. they need to have working unit tests that are all passing, needs to have Code Review (if you do them). Etc… Another thing that improves the speed of story completion in a DEV/QA environment is what I call buddy testing.
Dev and Test both identify the cards they plan to work on (this is a forecast not a commitment to that card. things always change).
When DEV is done they get up and go find that tester. They sit down side by side and walk them through the working code they have written. QA will inevitably say, “try this” or “Try that” and break the story. Then DEV can, often times quickly, make the fix right there and try it again.
only after buddy testing does the card move to QA.
This catches a ton of easy breaks early and saves a lot of time spent documenting in JIRA, assigning to QA, QA loading the code recreating, breaking the code, then documenting the error, then passing it back to DEV.
All that said. don’t change too many things at once. 😉 or you will overwhelm the team with change and they will slow down because of it.
On Wed, Sep 14, 2016 at 11:47 AM, AB [firstname.lastname@example.org] wrote:
We recently added the column, and it is helpful to have that visibility. We do have code review. Unit testing is still in the works. In place of that, in addition to code review, DEV performs functional testing based on test cases before hand off.
How do you set expectation on the amount of work that can be done within say, 3 sprints? Do you get story points estimates for 3 months’ worth? We need this data point to set expectations for the customers.
On Wed, Sep 14, 2016 at 4:29 PM, AB [email@example.com] wrote:
I guess my question is, do we get stories estimated by developers several months ahead of time, to know when a specific set of features will be completed?
On Thu, Sep 14, 2016 at 1:21 PM, Joseph Flahiff, Whitewater Projects, Inc <firstname.lastname@example.org> wrote:
You need to provide dates. But don’t ever provide a single date. Provide a confidence interval. That is a range of dates with high probability of completion on one end and low probability on the other. This can safely be done with some statistical analysis of your backlog for months even up to a year out. That is how we can do strategic planning. The process has a few steps though and is a bit complex. Once you get it down though you can use it easily and make updates to your stakeholders regularly. they love it! This was pioneered by a guy named Troy Magennis (http://focusedobjective.com/)
At first not having a single date makes sponsors nervous, but they quickly come to love it. With this approach, you can have more accurate estimations that we were ever able to get with any waterfall estimation approach (Critical Chain, PERT, or other methods).
Let me know if you have any questions.
On Mon, Nov 14, 2016 at 4:28 PM, Joseph Flahiff, Whitewater Projects, Inc <email@example.com> wrote:
It has been quite for a while since we chatted.
How are things going? Did my comments about statistical analysis of predictability make sense?
On Tue, Nov 15, 2016 at 11:47 PM, AB wrote:
Going ok. I looked up story boarding[mapping], The [company product] is not very modular. It is complex and sometimes our most senior developer underestimates the work.
Prior to this, each developer had their own story points scale, so this a big improvement already.
As far as level-of-effort estimates, we’re still asking developers to provide the story points for the product team to better plan the releases, so far that data point is not readily available.
DEV/QA sprints are working for us overall (incorporating functional testing into the sprints, along with development)
As far as story points go, we use a scale like this:
1 Complete in a few hours
2 twice the effort (or a day/or two)
3 1 sprint
5 Over 1 sprint
8 Too complex to know
On Wed, Nov 16, 2016 at 9:58 AM, Joseph Flahiff, Whitewater Projects, Inc <firstname.lastname@example.org> wrote:
Part of the problem with not being able to predict delivery is the way the teams are using story points. Which is, not as story points. Here is a webinar I did a few years back explaining why it is CRITICAL that story points be agreed upon abstract-measure, NOT tied to a unit of time. Check it out and let me know if it makes sense: https://www.youtube.com/watch?v=rTJLsxWa4Bk
If this sounds too familiar give me a call I would love to work with you to get your teams running better.
This is a real conversation. I will continue to update it as we continue the conversation.