Timeline for Influence code quality as Scrum Product Owner
Current License: CC BY-SA 3.0
5 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
May 31, 2016 at 13:29 | comment | added | CBRF23 | Also, I do agree with your assertion the product owner can add anything they like to the backlog. Part of the INVEST acronym is "negotiable" and that's where a good team will help you to weed out or improve bad stories :) | |
May 31, 2016 at 13:28 | comment | added | CBRF23 | Yes, very true - in that case, since it's a requirement of the customer and represents value to the customer, I would say it's a good story. However, if your customer was just going to be on subscription, it would not be a good story, as they just want working product, and could probably care less wether you use TFS or GIT or whatever to manage source code. I think part of being a good product owner is being able to make these types of judgment calls, and having a good team of developers to call your sh*t when you mess up :) | |
May 31, 2016 at 12:41 | comment | added | Ewan | I tend to agree. However its kinda vague, say im delievering a system which will be maintained by the customer going forward they might well have 'use TFS for source control' style requirements. | |
May 31, 2016 at 9:47 | comment | added | CBRF23 | I disagree with the idea of writing development focused stories. In User Stories Applied Mike Cohn argues strongly (and in my opinion quite convincingly) for keeping stories limited to defining end user value. | |
May 30, 2016 at 23:07 | history | answered | Ewan | CC BY-SA 3.0 |