10 ms·

I think you've hit on the fundamental contradiction of agile and scrum. > An upload button alone is no user story, a story might be "As a user, I want to be ab

by lumost 8y ago

I think you've hit on the fundamental contradiction of agile and scrum. > An upload button alone is no user story, a story might be "As a user, I want to be able to import the Excel reports that I get from company $XY, so that I don't have to manually enter the data, and save a lot of time that way", ideally including a reason why that data needs to be there. The implementation of this functionality in a way that will delight customers could hypothetically take 3 weeks as it requires the implementation of an upload button, a datastore to store the uploaded values, and an integration into a legacy feeds system to get the spreadsheet's data to all of the places it needs to go. 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". Even worse scrum projects emphasize anti-patterns of "parallelizing" efforts, so we'll assign each of those smaller stories to separate individuals. While theoretically a customer focused engineer could look at the original user story, there is minimal incentive to do this - and most engineers will focus on pushing stories across the board, the upload button may or may not ever work in a way that customer's desired - and any attempt to fix it requires restarting the whole process.

perlgeek 8y ago
> 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.
tigershark 8y ago
I think you need better software developers or a better system if for a person in your team, fluent with the object model and the systems downstream, takes 3 weeks to import data from an excel sheet honestly...
- spookthesunset 8y ago
  > I think you need better software developers or a better system if for a person in your team, fluent with the object model and the systems downstream, takes 3 weeks to import data from an excel sheet honestly... Ah yes, nothing is better than questioning the estimate of a hypothetical user story that lacks any and all detail about the existing environment. Like, maybe 3 weeks is quick? Maybe there is all kinds of shit you didn't even think of at all? Maybe the excel sheet has all kinds of weird non-canonical data that makes it very hard to reliably import? Maybe nobody on the team ever touched an excel spreadsheet in their life, let alone imported one? Like.... seriously. Are you one of those people who always go "you people are idiots, I can do task XYZ in 1/3 of the time all you estimated"? When an engineer tells you something will take 3 weeks, you listen to them.
  - tigershark 8y ago
    If it takes three weeks to import an excel sheet either you change your system or your engineers. tertium non datur.
    - scarmig 8y ago
      All the most profitable companies I've ever worked for, which also have had the smartest engineers I've worked with, would take longer than three weeks to build an Excel sheet import system. An engineer thinking it can be done correctly in three weeks, without bothering to know all the requirements, would be a red flag for all except the most junior of positions.
      - wolco 8y ago
        A junior engineer thinks speed is the most important metric.
scarface74 8y ago
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". ....Even worse scrum projects emphasize anti-patterns of "parallelizing" efforts, so we'll assign * There is often so much wasted effort in parallelizing work. I just implemented a feature that was two months worth of work by myself. I loved being able to think holistically and make changes up and down the stack from the interface (Api calls) to the Devops. I could make breaking changes between every part of the process and not have to work with five other people. I could easily see “war rooming” it with one other developer though and breaking it down between the two of us where we could just discuss the breaking change and make changes.
- ozmbie 8y ago
  To play Devil’s advocate: that’s 2 months a customer went without being able to use that feature. What could you or the company have learned if you shipped an earlier version and measured how people used it? Was your feeling of control and happiness worth the business information of not having that feature in the wild for 2 months?
  - wolco 8y ago
    To play devil's advocate. Other work can be assigned so in two months the customer gets the entire website. If they did it the other way every two weeks something would be finished but at the end they need to rewrite the backend adding an addional months because they didn't have the chance to look ahead and see that module 1 and 2 can't run at the same time.
    - scarface74 8y ago
      Which is actually very relevant to the project that I’m referring to. All four services were database intensive. They all worked perfectly independently. But when messages started at service 1, did some database work and put a message in the queue to kick off the next process and so on. When all four were running at the same time processing messages, the database screamed and made the website unresponsive. It took me longer to tune performance than to write the code. Can you imagine four developers working together tweaking code, queries, indexes, number of simultaneous threads, etc?
wavefunction 8y ago
Three weeks? Are you employing non programmers to program?
- ArchTypical 8y ago
  > implementation of an upload button Design team makes a mock that is styled and placed correctly, including moving around exiting elements in the page. > a datastore to store the uploaded values Just 1 datastore? More like: + a frontend service to get/put and validate the data is in the right format with sizing + a backend storage service (hardened because we don't know what's in the document) for get/put with sizing and validation optionally - an integration into a legacy feeds system to get the spreadsheet's data to all of the places it needs to go Ensure Legal, ADA, FDA, whatever compliant. Document EVERY decision along the way and coordinate. 3 weeks looks a little hight to me, but things tend to go awry with so many moving parts.
Jach 8y ago
In most scrum processes the devs just want to get going and don't want to waste more time breaking it down in even more meetings, so they might think that the story will take 3 weeks for dev effort + QE effort (we at least combine the efforts in our estimates) but still estimate it as 2 max (expressed as a point number of course, which is going to necessarily be a rough estimate) so they can get going. Another common thought is "1-3 weeks, not sure yet, need to get going to provide a better estimate, can't estimate well enough until then even if we try to break things down." Maybe as the replies suggest, it gets dev-done in less than a week despite the longer estimates, and if you're lucky QE picks it up and closes it before the end of the next week. The usual outcome for these types of stories is that one or the other takes longer, or the sprint was packed with too many 2-3 day bits of work that kept getting prioritized over QEing the big one, and now you have bleed-over as you push it to the next sprint (along with any 2-3 day stuff that you started on Friday because you were free). Bleed-over is the normal way you get > 2 weeks of work stories done, and is also a consequence of smaller things not perfectly fitting into the two week period as well. My team had these problems with the scrum process and switched over to a kanban style a couple years ago, it's been better for everyone. Because of the concept of WIP limits at each major stage in the pipeline, we get parallelism where it matters -- i.e. people unclogging the pipe: if the WIP limit is reached for dev-in-progress work and someone is looking for new work, it has to be something later in the pipeline. Because we don't do things in chunks of 2-weeks, if something takes longer than 2 weeks to get through the complete pipeline, no biggy, some work is just optimally sized for one person to spend a few weeks on to do the best job. (But that ended up happening less because of the WIP limits helping to force us to get things through instead of sitting around in one state forever.) And if you want to start something new on a Friday, no biggy, we don't have to argue over bleed-over and trying to optimize the bucket of new things per sprint for the next sprint with the other rule of not bringing in new things. (Sprint models are so obviously defective when you've finished up everything in the sprint on a Thursday morning. What are you going to do for the next day and a half if you have the rule that you can only add stuff to the board during sprint planning? Well the answer some shops give is you add something anyway, and it immediately bleeds over, and then you get criticized for bleed-over.)
- lstamour 8y ago
JohnBooty 8y ago
I know Scrum so I'm writing from that perspective. I'm not sure about "agile." In my experience, "agile" means "we have no workflow and it's a fucking madhouse." > 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". Yeah absolutely. But what's wrong with that? At some point, this will need to happen. One of the primary values of Scrum is that it forces you to break a story down into discrete tasks and estimate them as a team before the work begins. This is a great chance to pool your knowledge as a team. Suppose a team consists of developers A, B, C, D, and E. Well, implementing the Excel imports might involve 3 smaller stories. The first story might involve concerns that A and E have, and maybe there's actually a really easy way to do it that C knows about because she's done it before, and D's done it before too and knows about some pitfalls. That's a friggin great conversation to have. Now, you don't need Scrum to have that conversation, but Scrum's cool because it makes it nearly impossible to avoid it. Now, naturally, you certainly don't need Scrum to have that conversation! A healthy team of high achievers with great communication skills would have it anyway! But, the reality is... that conversation often doesn't happen without some kind of process (Scrum, or whatever) to make sure it happens. > Even worse scrum projects emphasize anti-patterns of "parallelizing" efforts This is really not my experience with Scrum at all and I'm confused as to why you think this harmful sort of "parallelization" (the kind proscribed by "The Mythical Man-Month") is some intrinsic part of agile/Scrum. Not familiar with Jira, but we used Pivotal Tracker and it lets you specify which stories are blocking other stories.
- sobani 8y ago
  @lumost wasn't talking about splitting up a story into tasks, but splitting a story up into 'stories', because the actual story is to large to fit into a single sprint. So what you end up with are several 'stories' that are basically collections of tasks from the actual story. Each of those 'stories' barely make sense on their own and it makes about as much sense to delay the last 'story' and use the intermediate result as it would be to delay the installation of the engine into a car.
OnlyRepliesToBS 8y ago
delighted users
arendtio 8y ago
> I think you've hit on the fundamental contradiction of agile and scrum. IMHO, Scrum is a tool bring an agile development process to a classical project organization. The idea behind Scrum is to build your own 'bubble' (the development team) where you can use an agile approach while assigning people who are meant to manage the interactions with the rest of the organization (Scrum Masters). So in the end, Scrum is some kind of practical approach to bringing agile development practices to large organizations and obviously, that is a compromise. So there is no contradiction, it is just that Scrum is not the solution, but a (first stage) tool to change existing organizations to become the agile organizations we would like to work within. Sadly many companies think they are 'Agile' once they adopted Scrum, but often they embraced the 'Processes and Tools' while agile clearly states that 'Individuals and interactions' are the relevant part: http://agilemanifesto.org http://agilemanifesto.org
- pjmlp 8y ago
  That is how it starts, but on the customers I have worked so far it eventually evolves into a kind of mini-waterfall when the development team needs to interact with other departments, and moving tasks between sprints is yet another common activity. Ah, and then there are the projects where Jira items are mapped into SAP items for project accounting, which introduce yet another "not so fun" discussion about when projects activities are supposed to be paid.
- jacobherrington 8y ago
  I've literally always felt that Scrum and the Agile Manifesto were at odds due to Scrum's focus on process. I always have trouble communicating this though.
tnolet 8y ago
This is what epics are for and they are right there in Jira. 1. Create epic with full context. 2. Create sub stories or tasks that describe the smaller deliverables. 3. Boom. Small tasks with a direct link to larger context. Works 100% fine in Jira and has since the early days.
lmm 8y ago
> The implementation of this functionality in a way that will delight customers could hypothetically take 3 weeks as it requires the implementation of an upload button, a datastore to store the uploaded values, and an integration into a legacy feeds system to get the spreadsheet's data to all of the places it needs to go. > 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". You can always find some way to implement something valuable to the user in less than 2 weeks if you actually try. Don't give them an upload button that doesn't go anywhere: give them an end-to-end integration that only works for one of the reports. Give them a network path where they have to save the sheet with a hardcoded filename, if that's still going to save a lot of time compared to manual data entry. Build end-to-end paths that you can widen out, not vertical slices that are useless until you've done all of them.
- MacroChip 8y ago
  Great comment. Most if not all other comments were recommending/complaining about parallelizing horizontal slides. Like you said, vertical slices are generally valuable to an end user, even if that first one is ugly, not user friendly, etc. Horizontal slides are a gamble. You parallelize, but risk wasting considerable work.

by lumost 8y ago

perlgeek 8y ago

> 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.

tigershark 8y ago

I think you need better software developers or a better system if for a person in your team, fluent with the object model and the systems downstream, takes 3 weeks to import data from an excel sheet honestly...

spookthesunset 8y ago
> I think you need better software developers or a better system if for a person in your team, fluent with the object model and the systems downstream, takes 3 weeks to import data from an excel sheet honestly... Ah yes, nothing is better than questioning the estimate of a hypothetical user story that lacks any and all detail about the existing environment. Like, maybe 3 weeks is quick? Maybe there is all kinds of shit you didn't even think of at all? Maybe the excel sheet has all kinds of weird non-canonical data that makes it very hard to reliably import? Maybe nobody on the team ever touched an excel spreadsheet in their life, let alone imported one? Like.... seriously. Are you one of those people who always go "you people are idiots, I can do task XYZ in 1/3 of the time all you estimated"? When an engineer tells you something will take 3 weeks, you listen to them.
- tigershark 8y ago
  If it takes three weeks to import an excel sheet either you change your system or your engineers. tertium non datur.
  - scarmig 8y ago
    All the most profitable companies I've ever worked for, which also have had the smartest engineers I've worked with, would take longer than three weeks to build an Excel sheet import system. An engineer thinking it can be done correctly in three weeks, without bothering to know all the requirements, would be a red flag for all except the most junior of positions.
    - wolco 8y ago
      A junior engineer thinks speed is the most important metric.

scarface74 8y ago

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". ....Even worse scrum projects emphasize anti-patterns of "parallelizing" efforts, so we'll assign * There is often so much wasted effort in parallelizing work. I just implemented a feature that was two months worth of work by myself. I loved being able to think holistically and make changes up and down the stack from the interface (Api calls) to the Devops. I could make breaking changes between every part of the process and not have to work with five other people. I could easily see “war rooming” it with one other developer though and breaking it down between the two of us where we could just discuss the breaking change and make changes.

ozmbie 8y ago
To play Devil’s advocate: that’s 2 months a customer went without being able to use that feature. What could you or the company have learned if you shipped an earlier version and measured how people used it? Was your feeling of control and happiness worth the business information of not having that feature in the wild for 2 months?
- wolco 8y ago
  To play devil's advocate. Other work can be assigned so in two months the customer gets the entire website. If they did it the other way every two weeks something would be finished but at the end they need to rewrite the backend adding an addional months because they didn't have the chance to look ahead and see that module 1 and 2 can't run at the same time.
  - scarface74 8y ago
    Which is actually very relevant to the project that I’m referring to. All four services were database intensive. They all worked perfectly independently. But when messages started at service 1, did some database work and put a message in the queue to kick off the next process and so on. When all four were running at the same time processing messages, the database screamed and made the website unresponsive. It took me longer to tune performance than to write the code. Can you imagine four developers working together tweaking code, queries, indexes, number of simultaneous threads, etc?

wavefunction 8y ago

Three weeks? Are you employing non programmers to program?

ArchTypical 8y ago
> implementation of an upload button Design team makes a mock that is styled and placed correctly, including moving around exiting elements in the page. > a datastore to store the uploaded values Just 1 datastore? More like: + a frontend service to get/put and validate the data is in the right format with sizing + a backend storage service (hardened because we don't know what's in the document) for get/put with sizing and validation optionally - an integration into a legacy feeds system to get the spreadsheet's data to all of the places it needs to go Ensure Legal, ADA, FDA, whatever compliant. Document EVERY decision along the way and coordinate. 3 weeks looks a little hight to me, but things tend to go awry with so many moving parts.

Jach 8y ago

In most scrum processes the devs just want to get going and don't want to waste more time breaking it down in even more meetings, so they might think that the story will take 3 weeks for dev effort + QE effort (we at least combine the efforts in our estimates) but still estimate it as 2 max (expressed as a point number of course, which is going to necessarily be a rough estimate) so they can get going. Another common thought is "1-3 weeks, not sure yet, need to get going to provide a better estimate, can't estimate well enough until then even if we try to break things down." Maybe as the replies suggest, it gets dev-done in less than a week despite the longer estimates, and if you're lucky QE picks it up and closes it before the end of the next week. The usual outcome for these types of stories is that one or the other takes longer, or the sprint was packed with too many 2-3 day bits of work that kept getting prioritized over QEing the big one, and now you have bleed-over as you push it to the next sprint (along with any 2-3 day stuff that you started on Friday because you were free). Bleed-over is the normal way you get > 2 weeks of work stories done, and is also a consequence of smaller things not perfectly fitting into the two week period as well. My team had these problems with the scrum process and switched over to a kanban style a couple years ago, it's been better for everyone. Because of the concept of WIP limits at each major stage in the pipeline, we get parallelism where it matters -- i.e. people unclogging the pipe: if the WIP limit is reached for dev-in-progress work and someone is looking for new work, it has to be something later in the pipeline. Because we don't do things in chunks of 2-weeks, if something takes longer than 2 weeks to get through the complete pipeline, no biggy, some work is just optimally sized for one person to spend a few weeks on to do the best job. (But that ended up happening less because of the WIP limits helping to force us to get things through instead of sitting around in one state forever.) And if you want to start something new on a Friday, no biggy, we don't have to argue over bleed-over and trying to optimize the bucket of new things per sprint for the next sprint with the other rule of not bringing in new things. (Sprint models are so obviously defective when you've finished up everything in the sprint on a Thursday morning. What are you going to do for the next day and a half if you have the rule that you can only add stuff to the board during sprint planning? Well the answer some shops give is you add something anyway, and it immediately bleeds over, and then you get criticized for bleed-over.)

lstamour 8y ago

JohnBooty 8y ago

I know Scrum so I'm writing from that perspective. I'm not sure about "agile." In my experience, "agile" means "we have no workflow and it's a fucking madhouse." > 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". Yeah absolutely. But what's wrong with that? At some point, this will need to happen. One of the primary values of Scrum is that it forces you to break a story down into discrete tasks and estimate them as a team before the work begins. This is a great chance to pool your knowledge as a team. Suppose a team consists of developers A, B, C, D, and E. Well, implementing the Excel imports might involve 3 smaller stories. The first story might involve concerns that A and E have, and maybe there's actually a really easy way to do it that C knows about because she's done it before, and D's done it before too and knows about some pitfalls. That's a friggin great conversation to have. Now, you don't need Scrum to have that conversation, but Scrum's cool because it makes it nearly impossible to avoid it. Now, naturally, you certainly don't need Scrum to have that conversation! A healthy team of high achievers with great communication skills would have it anyway! But, the reality is... that conversation often doesn't happen without some kind of process (Scrum, or whatever) to make sure it happens. > Even worse scrum projects emphasize anti-patterns of "parallelizing" efforts This is really not my experience with Scrum at all and I'm confused as to why you think this harmful sort of "parallelization" (the kind proscribed by "The Mythical Man-Month") is some intrinsic part of agile/Scrum. Not familiar with Jira, but we used Pivotal Tracker and it lets you specify which stories are blocking other stories.

sobani 8y ago
@lumost wasn't talking about splitting up a story into tasks, but splitting a story up into 'stories', because the actual story is to large to fit into a single sprint. So what you end up with are several 'stories' that are basically collections of tasks from the actual story. Each of those 'stories' barely make sense on their own and it makes about as much sense to delay the last 'story' and use the intermediate result as it would be to delay the installation of the engine into a car.

OnlyRepliesToBS 8y ago

delighted users

arendtio 8y ago

> I think you've hit on the fundamental contradiction of agile and scrum. IMHO, Scrum is a tool bring an agile development process to a classical project organization. The idea behind Scrum is to build your own 'bubble' (the development team) where you can use an agile approach while assigning people who are meant to manage the interactions with the rest of the organization (Scrum Masters). So in the end, Scrum is some kind of practical approach to bringing agile development practices to large organizations and obviously, that is a compromise. So there is no contradiction, it is just that Scrum is not the solution, but a (first stage) tool to change existing organizations to become the agile organizations we would like to work within. Sadly many companies think they are 'Agile' once they adopted Scrum, but often they embraced the 'Processes and Tools' while agile clearly states that 'Individuals and interactions' are the relevant part: http://agilemanifesto.org http://agilemanifesto.org

pjmlp 8y ago
That is how it starts, but on the customers I have worked so far it eventually evolves into a kind of mini-waterfall when the development team needs to interact with other departments, and moving tasks between sprints is yet another common activity. Ah, and then there are the projects where Jira items are mapped into SAP items for project accounting, which introduce yet another "not so fun" discussion about when projects activities are supposed to be paid.
jacobherrington 8y ago
I've literally always felt that Scrum and the Agile Manifesto were at odds due to Scrum's focus on process. I always have trouble communicating this though.

tnolet 8y ago

This is what epics are for and they are right there in Jira. 1. Create epic with full context. 2. Create sub stories or tasks that describe the smaller deliverables. 3. Boom. Small tasks with a direct link to larger context. Works 100% fine in Jira and has since the early days.

lmm 8y ago

> The implementation of this functionality in a way that will delight customers could hypothetically take 3 weeks as it requires the implementation of an upload button, a datastore to store the uploaded values, and an integration into a legacy feeds system to get the spreadsheet's data to all of the places it needs to go. > 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". You can always find some way to implement something valuable to the user in less than 2 weeks if you actually try. Don't give them an upload button that doesn't go anywhere: give them an end-to-end integration that only works for one of the reports. Give them a network path where they have to save the sheet with a hardcoded filename, if that's still going to save a lot of time compared to manual data entry. Build end-to-end paths that you can widen out, not vertical slices that are useless until you've done all of them.

MacroChip 8y ago
Great comment. Most if not all other comments were recommending/complaining about parallelizing horizontal slides. Like you said, vertical slices are generally valuable to an end user, even if that first one is ugly, not user friendly, etc. Horizontal slides are a gamble. You parallelize, but risk wasting considerable work.