SDLC Stories & Story Point across multiple disciplines (Dev & QA)

[James Gould]

Good Day,

 I am wondering how others use JIRA tickets & Story points to track burndown in a sprint.

 My organization creates a Story and comes up w/ and estimate based on the LOE agreed on by development (web & backend) and QA. The challenge is that the Story often will be in more than one sprint as the development is completed and then the testing takes place.

 This makes the sprint burndowns always end with story points not completed and sprints always having a higher initiated work than completed.

 Have others run into this challenge and if so what is you approach to try and avoid so many stories spanning multiple sprints?

 Appreciate any feedback.

~Jim

[Danut M _StonikByte_]

Hi @James Gould,

The process you describe looks like "waterfall in sprint" (or in multiple sprints). You still have separated development & testing phases and testing is totally decoupled from development, which is not what agile recommends.

Agile testing means that development and testing happen as a single process, during the same sprint. Story sizing should combine development and testing, programmers and testers should work closely together (that's why agile teams are cross-functional and team members are co-located), and there should be multiple testing cycles within story development, with multiple feedback loops from the tester to the programmer until the story is complete (development + testing + bug fixes) in the same sprint.  

I highly recommend the book "Agile Testing: A Practical Guide for Testers and Agile Teams" by Lisa Crispin and Janet Gregory, which would help you better integrate development and testing in your agile implementation.

Hope this helps.

Danut

[James Gould]

Thank you Danut,

 I appreciate the answer.

 How do you use JIRA for this scenario "...with multiple feedback loops from the tester to the programmer until the story is complete..." when it can not be completed in the same sprint?

 Do you just roll the stories to the next sprint?

 How does that impact you sprint planning and how you think about the teams velocity?

 Would really appreciate any feedback or examples that you can share.

~Jim

[Danut M _StonikByte_]

Hi @James Gould,

To integrate the testers in the process, we have a testing column on the team board. So our board has these columns:

BACKLOG | IN PROGRESS | IN TESTING | DONE 

Then, we ensure that the user stories are small enough in order to be fully worked in a sprint (developed, tested, and bug-fixed). So make sure that you split your stories in such a way to fit a sprint. Also, you can increase the duration of the sprint to make sure that it is large enough to have the majority of the stories completed in one sprint. For example, if you have sprints of 2 weeks, try making them 3-weeks long. 

We do not have separated testing tasks for the testers. When a programmer has a story ready for testing, he moves the issue to In Testing column and let's the tester know. Because they are in close collaboration, they discuss directly. The tester communicates directly with the developer, gives verbal feedback about the issues found, and the developer makes the necessary corrections right away. If the bug fix is more complicated, the story is moved back to In Progress... and so on. We avoid adding bugs (because bugs are just waste - time spent filling forms); we prefer direct communication between tester and programmer.

There are rare cases when a story is too large for a sprint, and cannot be split in multiple stories. In these rare cases, we commit it in a sprint and we finish it in the next sprint - without splinting the Story Points across sprints. So, yes, we move the entire story in next sprint if it is incomplete. If a story has 20 SPs, we commit it in Sprint A, and finish it in Sprint B. In sprint planning meeting for Sprint B we consider the remaining work on this story, when we do our sprint commitment. 

And the points will appears as done in Sprint B. Velocity is impacted a bit, but not too much because our team velocity is calculated as the average of a few past sprints (3).

Hope this helps.

Danut.   

[James Gould]

Thanks @Danut M _StonikByte_ 

 Appreciate that.

If you dont mind me asking, do you have a single team or multiple teams?

How big are the teams?

Are you running 2,3,or 4 week sprints?

Full stack developers or discipline specific developers (Web/Back End)?

Do developers help test(beyond unit), dont pick up another ticket until the one being tested is done/done, or do they move to the next priority ticket in the sprint?

If they move on how do you avoid the waterfall effect?

If they dont move on does that impact the team throughput (developers not developing)?

How often do your teams deploy to production?

~Jim

[Danut M _StonikByte_]

Hi @James Gould,

I could offer these details in a private discussion.

Perhaps the via the LinkedIn chat. Please sent me an invite.  

Danut Manda

[James Gould]

@Danut M _StonikByte_You are a scholar and a gentleman, much appreciated.

~Jim