8 ms·

> In most scrum processes 3 weeks of effort would not be accepted, and the story would be "broken down" into smaller issues such as "implement an upload button"

> In most scrum processes 3 weeks of effort would not be accepted, and the story would be "broken down" into smaller issues such as "implement an upload button". Yes, but a good scrum process goes like this: 1) the PO presents the story 2) the developers discuss it, and find that it doesn't fit into a single sprint 3) developers and PO together break it down into small issues, for example by turn the original story into an epic, and creating more, smaller issues in that epic. So when a developer works on the smaller story, they have heard about the context before, and have a link to the epic with the broader context in case they have forgotten. It's not automatically provided by Jira, but if you use the tools correctly, you can absolutely provide that context.

spdionis 8y ago
Indeed the main point to provide context in the scrum process is the refinement meeting.
- njanse 8y ago
  I completely agree, the refinement meeting is the key. We've just spent a year interviewing 200+ product owners about the problem that the article are describing. For most teams, JIRA works great for monitoring progress on closely defined tasks, but context "above story level" is a real problem. The better teams do already use another tool than JIRA to write such documents, typically at "epic level", and typically using Google Docs and/or Confluence. But almost all struggle with writing this document, where common problems include: * duplication of work and manual updating between the document and JIRA * unclear handover of the source of truth, since things that are written in the document are "true until stated otherwise in JIRA or a JIRA comment.. or somewhere on Slack" * lots on input/questions/decisions from refinement meetings not captured in either the document or in JIRA I think the solution is to think of this document less as a "requirements document" (many label this doc a "PRD"), and more as a "refinement document". This "refinement document" should * try to capture the conversation that happens in refinement meetings * involve also the developers to cover not only "why" and "what", but also a bit of "how" * evolve and be updated all the way through development as new insights are gained * be the source of truth and available to the developer working on the JIRA issue We have made a tool specifically to support working this way with "refinement documents". One dedicated place to refine features. Structure, collaborate, keep track of questions and capture not only decisions, but also conversations. Seamlessy transform your work into crystal clear Jira epics and stories. When you turn notes into Jira issues, you can see all the details via our Jira plugin. Happy to hear your thoughts, please do check it out at https://www.delibr.com/ https://www.delibr.com/
joejerryronnie 8y ago
Mature empowered teams will also discuss the cost/benefit to determine if the feature is really worth the effort entailed in light of the thousand other priorities in the backlog. Sometimes this leads to alternate, more efficient approaches to addressing the need or at least a healthy discussion on the true MVP of the feature.
iaresee 8y ago
JIRA could work better in this situation if it allowed for deeper nesting of tickets. You could still capture the larger user story and then subdivide below that level into smaller stories and then features with tasks.
- crisnoble 8y ago
  It does. My team uses Epics -> Stories -> Sub Tasks all the time.
  - iaresee 8y ago
    That’s not enough to represent large, complex projects. And sub-tasks are implemented in this weird, dystopian way that makes them unreasonably hard to work with in the system.
    - slider_thor 8y ago
      You should check out the Structure add-on. Does unlimited hierarchies in a very intuitive way. Only for on-premise.
    - geerlingguy 8y ago
      Agreed, the few times we've tried moving from separate linked tickets to sub-tasks have been disasters. It doesn't jive with any of the tooling in Jira to try to have tickets be like 'mini-Epics'.
  - yxhuvud 8y ago
    That is not enough! I regularly want to create sub tasks to subtasks, but it is not possible.
    - Klinky 8y ago
      You could also link to other tickets or Epics with "relates to" or "blocked by".
renox 8y ago
Bah this process is faulty, we use it at work and this means that a feature which has to manage N things is almost always split into 'manage 1 thing' then 'goes from 1 to N' even though it takes more work and the resulting code is much more ugly..
- merb 8y ago
  i've seen plenty of people that tried to tackle a big problem at once and the result was way more ugly than just split the problem up. at my work place my boss always writes down the complete issues/features and let the people do them however they like, but most of the time this is bad, because doing something at once without a certain structure will yield a way bigger mess than if the thing would've been splitted.
  - wolco 8y ago
    That's why you pay for experience. Doing it at once leads to better overall design provided the developer can produce proper structure on there own.
    - notduncansmith 8y ago
      There are two primary styles of software development. The first is “make the change/feature easy, then make the easy change/feature”. I call this Structure-Driven Development (SDD), because the features of the software are emergent properties of the structure of the system. This often concerns various “layers” of the system (HTTP, auth, validation, data access, error-handling, etc). The second is “make the change that’s currently easiest”. I call this Feature-Driven Development (FDD), because the structure of the app is whatever emerges from feature development. This, naturally, concerns the various features of the software itself, spread across whatever primitive components are already available and usually copying structure from the first few features written. IMO, successful agile product development involves a mix of these styles. SDD produces better structure at the expense of heavy up-front development costs. FDD helps you figure out where to apply SDD. I like to start projects with SDD for the first few weeks of a project, then alternating styles every 2 weeks to test and refine structural assumptions (think of it like a REPL for architecture). This also helps keep teams from getting too stuck in either style as many do. Get locked into SDD, end up not shipping a single feature for weeks. Especially prone to happening on single-developer projects. Especially unlikely with good project management + strong communication between engineers and stakeholders. Get locked into FDD, code yourself into corners, gradually building a pile of mud that no-one fully understands. Far less likely (but still possible) on single-developer projects. Senior engineering oversight and adequate time budgeting are critical to preventing this. Both styles have their tradeoffs, and like most things it takes experience/maturity and a dash of luck to navigate the balance successfully on a given project. One indicator that your SDD is working is that you do much less of it after the first month or two of development, as the structure will be in place and effort can largely shift to features and polish. EDIT: Cleaned this up into a post here https://medium.com/@hi_17592/software-development-styles-ebea14fdf4bd https://medium.com/@hi_17592/software-development-styles-ebe...
nautilus12 8y ago
Yes but the developers are incentivized to get it done as quickly as possible and if they start to present multiple steps their managers will be likely to acuse them of overengineering the system so they just try to do it all at once.
- tomaskafka 8y ago
  This sounds like a trust issue, not a Jira problem
  - closeparen 8y ago
    Jira encourages this kind of trust problem by framing the world in terms of ticket-closing velocity.
stupidbird 8y ago
Sounds like there's more overhead than work there.
- Haga 8y ago
  Yes, let's move fast and break things. Things like the architecture, the framework and team communication. Then once the tech debt avalanche rolls in move fast to a different company to break things there. Thus good hiring processes to to keep prototype programmers at bay.
  - gronne 8y ago
    Yeah - blame the developers. 90% of the “bad” code i have written was forced by the manager/company. The proper / structured way considered too expensive.
  - stupidbird 8y ago
    I'd rather break things than linger around in some obscured purgatory where a straightforward task is spread out across a dozen subtasks that ultimately end up being rewritten anyway because something changed during the month it took to get halfway there.
normtown 8y ago
Just take the 3 weeks to implement it. Process doesn’t exist to hold us hostage.

spdionis 8y ago

Indeed the main point to provide context in the scrum process is the refinement meeting.

njanse 8y ago
I completely agree, the refinement meeting is the key. We've just spent a year interviewing 200+ product owners about the problem that the article are describing. For most teams, JIRA works great for monitoring progress on closely defined tasks, but context "above story level" is a real problem. The better teams do already use another tool than JIRA to write such documents, typically at "epic level", and typically using Google Docs and/or Confluence. But almost all struggle with writing this document, where common problems include: * duplication of work and manual updating between the document and JIRA * unclear handover of the source of truth, since things that are written in the document are "true until stated otherwise in JIRA or a JIRA comment.. or somewhere on Slack" * lots on input/questions/decisions from refinement meetings not captured in either the document or in JIRA I think the solution is to think of this document less as a "requirements document" (many label this doc a "PRD"), and more as a "refinement document". This "refinement document" should * try to capture the conversation that happens in refinement meetings * involve also the developers to cover not only "why" and "what", but also a bit of "how" * evolve and be updated all the way through development as new insights are gained * be the source of truth and available to the developer working on the JIRA issue We have made a tool specifically to support working this way with "refinement documents". One dedicated place to refine features. Structure, collaborate, keep track of questions and capture not only decisions, but also conversations. Seamlessy transform your work into crystal clear Jira epics and stories. When you turn notes into Jira issues, you can see all the details via our Jira plugin. Happy to hear your thoughts, please do check it out at https://www.delibr.com/ https://www.delibr.com/

joejerryronnie 8y ago

Mature empowered teams will also discuss the cost/benefit to determine if the feature is really worth the effort entailed in light of the thousand other priorities in the backlog. Sometimes this leads to alternate, more efficient approaches to addressing the need or at least a healthy discussion on the true MVP of the feature.

iaresee 8y ago

JIRA could work better in this situation if it allowed for deeper nesting of tickets. You could still capture the larger user story and then subdivide below that level into smaller stories and then features with tasks.

crisnoble 8y ago
It does. My team uses Epics -> Stories -> Sub Tasks all the time.
- iaresee 8y ago
  That’s not enough to represent large, complex projects. And sub-tasks are implemented in this weird, dystopian way that makes them unreasonably hard to work with in the system.
  - slider_thor 8y ago
    You should check out the Structure add-on. Does unlimited hierarchies in a very intuitive way. Only for on-premise.
  - geerlingguy 8y ago
    Agreed, the few times we've tried moving from separate linked tickets to sub-tasks have been disasters. It doesn't jive with any of the tooling in Jira to try to have tickets be like 'mini-Epics'.
- yxhuvud 8y ago
  That is not enough! I regularly want to create sub tasks to subtasks, but it is not possible.
  - Klinky 8y ago
    You could also link to other tickets or Epics with "relates to" or "blocked by".

renox 8y ago

Bah this process is faulty, we use it at work and this means that a feature which has to manage N things is almost always split into 'manage 1 thing' then 'goes from 1 to N' even though it takes more work and the resulting code is much more ugly..

merb 8y ago
i've seen plenty of people that tried to tackle a big problem at once and the result was way more ugly than just split the problem up. at my work place my boss always writes down the complete issues/features and let the people do them however they like, but most of the time this is bad, because doing something at once without a certain structure will yield a way bigger mess than if the thing would've been splitted.
- wolco 8y ago
  That's why you pay for experience. Doing it at once leads to better overall design provided the developer can produce proper structure on there own.
  - notduncansmith 8y ago
    There are two primary styles of software development. The first is “make the change/feature easy, then make the easy change/feature”. I call this Structure-Driven Development (SDD), because the features of the software are emergent properties of the structure of the system. This often concerns various “layers” of the system (HTTP, auth, validation, data access, error-handling, etc). The second is “make the change that’s currently easiest”. I call this Feature-Driven Development (FDD), because the structure of the app is whatever emerges from feature development. This, naturally, concerns the various features of the software itself, spread across whatever primitive components are already available and usually copying structure from the first few features written. IMO, successful agile product development involves a mix of these styles. SDD produces better structure at the expense of heavy up-front development costs. FDD helps you figure out where to apply SDD. I like to start projects with SDD for the first few weeks of a project, then alternating styles every 2 weeks to test and refine structural assumptions (think of it like a REPL for architecture). This also helps keep teams from getting too stuck in either style as many do. Get locked into SDD, end up not shipping a single feature for weeks. Especially prone to happening on single-developer projects. Especially unlikely with good project management + strong communication between engineers and stakeholders. Get locked into FDD, code yourself into corners, gradually building a pile of mud that no-one fully understands. Far less likely (but still possible) on single-developer projects. Senior engineering oversight and adequate time budgeting are critical to preventing this. Both styles have their tradeoffs, and like most things it takes experience/maturity and a dash of luck to navigate the balance successfully on a given project. One indicator that your SDD is working is that you do much less of it after the first month or two of development, as the structure will be in place and effort can largely shift to features and polish. EDIT: Cleaned this up into a post here https://medium.com/@hi_17592/software-development-styles-ebea14fdf4bd https://medium.com/@hi_17592/software-development-styles-ebe...

nautilus12 8y ago

Yes but the developers are incentivized to get it done as quickly as possible and if they start to present multiple steps their managers will be likely to acuse them of overengineering the system so they just try to do it all at once.

tomaskafka 8y ago
This sounds like a trust issue, not a Jira problem
- closeparen 8y ago
  Jira encourages this kind of trust problem by framing the world in terms of ticket-closing velocity.

stupidbird 8y ago

Sounds like there's more overhead than work there.

Haga 8y ago
Yes, let's move fast and break things. Things like the architecture, the framework and team communication. Then once the tech debt avalanche rolls in move fast to a different company to break things there. Thus good hiring processes to to keep prototype programmers at bay.
- gronne 8y ago
  Yeah - blame the developers. 90% of the “bad” code i have written was forced by the manager/company. The proper / structured way considered too expensive.
- stupidbird 8y ago
  I'd rather break things than linger around in some obscured purgatory where a straightforward task is spread out across a dozen subtasks that ultimately end up being rewritten anyway because something changed during the month it took to get halfway there.

normtown 8y ago

Just take the 3 weeks to implement it. Process doesn’t exist to hold us hostage.