Timeline for Shared Development Tasks for Agile User Stories
Current License: CC BY-SA 4.0
16 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 25, 2018 at 13:46 | comment | added | Frayt | @BryanOakley Absolutely. The majority of "cards" on a board should be written in user-centric terms only, but exceptional cases (primarily technical stories which have been broken out for the purposes of estimation) require introducing technical language. | |
| Jul 25, 2018 at 12:10 | comment | added | Bryan Oakley | @AntP: how is scrum "pseudo-agile"? | |
| Jul 25, 2018 at 12:09 | comment | added | Bryan Oakley | @Frayt: you wrote "User stories should be written from a user perspective with no technical information." . Strictly speaking that may be true, but user stories aren't necessarily the only type of item on the product backlog. You can have other types of stories. | |
| Jul 25, 2018 at 10:45 | comment | added | Ant P | @Frayt that's not an attack, it's an observation on the cargo cult culture surrounding pseudo-agile methodologies like scrum. This is an observation on your position in this discussion. That's all. | |
| Jul 25, 2018 at 9:44 | comment | added | Frayt | @AntP Please don't turn a discussion into a personal attack. | |
| Jul 25, 2018 at 9:20 | comment | added | Ant P | @Frayt user stories are placeholders for conversations about how to solve a problem. If you've started designing the solution, you've started work on the story. I think you might have spent too much time reading Scrum 101 and not enough time practicing effective software delivery in the real world. | |
| Jul 25, 2018 at 8:59 | comment | added | Frayt | If you are not using sprints, you can break the story down into technical tasks once the story has been prioritised. | |
| Jul 25, 2018 at 8:54 | comment | added | Ant P | @Frayt "before the sprint" - who said anything about sprints? Sounds like you're stuck in mini-waterfall world. | |
| Jul 25, 2018 at 8:39 | comment | added | Frayt | -1: User stories should be written from a user perspective with no technical information. The development team should go through each user story before the sprint and add high level technical tasks (add field to db table, update build script, display field on UI). The devs agree on a technical architecture, reducing lost time from large revisions during code review. Also allows multiple devs to work on a story as each task is independent. | |
| Jul 19, 2018 at 21:30 | comment | added | RubberDuck | @Schmidty15 my (old) team used VSTS much like you are. We would not have even used tasks if we hadn’t a need for ISO-9001 compliance. We created tasks on the fly just prior to implementing the task solely so we had a way to track each commit back to a “requirement”. It was a convenient way for us to avoid the “I don’t have a work item for this refactoring” trap. Just food for thought. You might not even need to track the tasks at your shop. You may want to do it just in time for traceability purposes. | |
| Jul 19, 2018 at 18:51 | comment | added | Greg Burghardt | @Schmidty15: I did the same thing before too. And ran into the same problems. Treating agile like waterfall just means you encounter the same problems that come with waterfall development, except more frequently. | |
| Jul 19, 2018 at 18:40 | comment | added | Schmidty15 | I was treating User Stories / Tasks like a more "formal" Waterfall methodology. I was trying to think through and write out all of the Tasks needed to complete each User Story before development even started. I didn't understand the fundamental concept of Agile as being "pick a story, determine the tasks, implement, repeat". Agile makes more sense now, thank you! | |
| Jul 19, 2018 at 18:31 | comment | added | Greg Burghardt | +1 for "database stuff exists, let's just extend the UI." Our team did this exact thing earlier this morning, actually. It just means the story with the common stuff is a bigger story. Most likely it will be more story points than subsequent stories, unless the testing effort is larger. We had 1 "common stuff" story that ended up being 13 points. The next story was basically doing a smidgeon of database stuff, and extend the UI. It was also 13 points. Less development, but we identified many more test cases. The last story was much less than the other 3, because of fewer test cases. | |
| Jul 19, 2018 at 17:27 | vote | accept | Schmidty15 | ||
| Jul 19, 2018 at 16:30 | history | edited | Ant P | CC BY-SA 4.0 | added 103 characters in body |
| Jul 19, 2018 at 16:24 | history | answered | Ant P | CC BY-SA 4.0 |