15 ms·

I don't know if something is wrong with me, but I simply cannot "decompose" a single feature into 500 different sub-task Jiras. I understand why it would be su

I don't know if something is wrong with me, but I simply cannot "decompose" a single feature into 500 different sub-task Jiras. I understand why it would be super cool if software worked like that, but I have to iterate on features holistically and sometimes speculatively. At least for me, software development has never been able to be so cleanly broken down into "first, implement the button" type tasks. But maybe I'm just dumb.

virgil_disgr4ce 6y ago
> but I have to iterate on features holistically and sometimes speculatively. YES. THANK YOU! I've been trying to tell people this for ages. Maybe other people are somehow capable of perfectly predicting every conceivable edge-case and consequence without even starting to work on something, but I can't. I have to start building something in order to see it clearly. And this ENRAGES certain kinds of managers, I have found.
- deleted 6y ago
  [deleted]
- anon9001 6y ago
  Managers just want you to deliver on a predictable schedule. Here's how you can solve your problem: Make as many tickets as you can think of, it doesn't really matter if they contain the essence of the problem or not, it just matters that there are many tickets associated with the task. Once you have your tickets, estimate them with as much padding as possible. If the manager complains that you're padding a ticket too much, make two tickets and split the estimate. Once you have a big pile of tickets and estimates, you've bought yourself enough time to do the work. Go do the work, then mark all the tickets as complete. You'll figure out the edge cases as you go, as long as you've made enough tickets and time to do the job at a reasonable pace. If you have extra time left over, get started on the next thing, improve your tooling, or try to help someone else with their tasks. If you don't have extra time left over, make more tickets next time.
  - james-mcelwain 6y ago
    This is also what I do, but it seems so antagonistic and deceptive. I want my relationship with my PM to be productive and collaborative.
  - gilbetron 6y ago
    Managers want a fiction to present to their superiors - the most happy my managers are is when what you describe happens. I like your approach :) I might have to be more explicit in creating a fiction. The only issue is if/when you actually run into things that significantly delay things right towards the end.
  - alistairSH 6y ago
    Ack, please don't. As a manager, I'm pretty sure I'd see this as the bullshit it is and call you on it. We're not all morons.
    - anon9001 6y ago
      Where exactly is the problem with my strategy? I'm also a manager of a small team. My main goals are to make sure everyone is not idle, not burned out, and not missing deadlines. My boss's goal is to try and get everyone to work every waking hour so we can deliver faster. My job is primarily to keep the peace between the executives and the workers. When I fail the workers, it looks like unpaid overtime. When I fail the executives, it looks like undelivered features. I think the actual purpose of agile, from a developer's perspective, is to create more time to deliver quality engineering work product. From an executive's perspective, agile exists to squeeze developers into completing tickets faster. As a manager, it's my job to keep both parties as satisfied as possible. If engineers have enough time to build and executives get enough deliverables, then the company succeeds. What's your strategy?
      - alistairSH 6y ago
        I read your comment as "create as many tickets as necessary to throw off management's understanding of the effort and complexity of the problem." Creating more tasks than necessary sounds like a waste of everybody's time. As I noted in a parallel comment, on my team, developers are never creating tasks on their own or in a vacuum. It's done as a team effort during planning meetings. Perhaps I should add that my boss (senior director) has never asked me about my board, velocity, or anything like that. Discussion is higher level - "is project X on schedule?" or "are you going to miss anything on your roadmap?" not "why is task X or story Y not done yet?" If your director is asking that, he has too much time on his hands.
GrumpyYoungMan 6y ago
> "I simply cannot "decompose" a single feature into 500 different sub-task Jiras." Nobody can; that's the primary failure mode of waterfall. Anybody who is telling you to decompose a feature into that many subtasks might claim to be doing agile but they really are trying to do waterfall.
- deleted 6y ago
  [deleted]
- mumblemumble 6y ago
  > that's the primary failure mode of waterfall That's the primary failure mode of a straw man software development methodology called waterfall that Scrum practitioners like to use as a bogeyman to appeal to for rhetorical purposes during the inevitable arguments about niggly little details of how to implement Scrum during sprint retrospectives. I've never actually done real waterfall, but I did study it way back when I was in college, and I have worked in government contracts, which tend to handle the work in a way that is similar to the waterfall I read about in school. One thing I distinctly remember is that it was designed to be a flexible and iterative methodology that would have been difficult to cram into a ticketing system in the first place, let alone cram into Jira while simultaneously carving the work into tiny pieces, up front, all at once. FWIW, the only place I've ever been asked to do something like that is in ostensible Scrum shops. In fact, the only time I've ever seen anything that looks like the Waterfall of scrum lore is in shops that are trying to do Scrum. I am beginning to suspect that the Waterfall of Scrum lore isn't actually a thing that happens outside of Scrum at all. It's actually what naturally tends to emerge when you try to apply Scrum methodology in a situation where something along the lines of the real, textbook waterfall model would have been more appropriate. As a concrete example, I currently work at a team that ostensibly uses Scrum, but where QA is a separate department with its own practices that the dev team does not control. They do still want some ability to anticipate work that's coming their way, though, so they're monitoring the scrum board for that purpose. This is the moment where it gets messy, because we're then asked to document things ahead of time, and it's a minor crisis if we keep it flexible during the sprint because any changes to the set of tickets becomes an inevitable hassle as they complain that we've screwed up work product that they generate based on those tickets. It's absolutely something straight out of waterfall horror stories from Scrum lore. But it's only happening because we're doggedly insisting on something that's at least cosmetically similar to scrum. If we weren't doing that, we'd be freer to choose modes of interaction and business artifacts that are better suited to the reality we occupy.
goalieca 6y ago
No, you're not dumb. Telling someone precisely how to work and then tracking every bit of it is called micro-management.
danieldisu 6y ago
Don't get me started when they try to push all clients into one jira, each one of them with their own complexities, release cycles etc. Or when they try to measure team effectiveness using Jira un some way or another, every team is capable of doing more Jiras in the same time by just splitting them more!
anthonyrstevens 6y ago
Nobody can. But anybody can ask "What is the next task that needs to be done?"
- loopz 6y ago
  So building constructions blindfolded is the norm? Sounds like recipe for entangled messes. It has always been at systems thinking, design and architecture, in that order. Doing it organically is a magic feat rarely done well.
HeyLaughingBoy 6y ago
It can usually be done. The problem is that people assume that now that you have that list of subtasks, you can iterate through them one at a time until you've built the feature. That's the major disconnect. What I do with my guys is I make them decompose the feature, but with the understanding that they'll probably be jumping from one subtask to the other, back and forth, as they understand what it is they'll be building. AND they'll probably come across new subtasks as they work through the feature. It makes Jira look crappy, but it Reflects Reality (tm) which to me is far more important than keeping Jira clean.
- Ididntdothis 6y ago
  That's how it works. Touch something here, touch something there, learn from it and slowly build up the whole thing. I think Scrum and Kanban may work if you have a somewhat mature system where you add incremental features but if you do something relatively new and big the backlog can not reflect reality. Or it forces a workflow that doesn't make sense. I have seen it multiple times where people refused to make changes to something because their story was done already. Never mind that the design turned out to be unsuitable.
  - mark-r 6y ago
    I saw this happen before Agile was even a thing. The possibility of a bug in the spec was never a consideration. You had to hope your assumptions going in were correct, or your users were screwed.
    - HeyLaughingBoy 6y ago
      A story I love to tell is the time where I was in the medical device industry. A requirement was formally reviewed with the owner and he signed off on it. The design was completed and reviewed and found to match the requirement, I implemented it, tested it and found it worked as expected and handed off to QA. QA tested it and verified that it correctly implemented the Requirement. The feature was turned over to its owner for so he could use it and his response was "that's not what I asked for!"
gdilla 6y ago
What I find helpful as a product manager, I discuss each feature with engineers - and we collaboratively break it down into a bare-bones "MVP" version, but consider nice to haves as future stuff or TBD based on what we learn. That helps push scope down and manage holistic iteration. Every feature should have an MVP version of it. At least asking the question can help break down that first user story.
- texasbigdata 6y ago
  How did you learn this?
  - burner831234 6y ago
    I learned it through the job. I think thats the quiet secret. Engineering is best learned through a form of apprenticeship but so is product.
    - loopz 6y ago
      Too bad corps optimize away apprenticeship, and then wonder why their processes delivers less and less...
  - gdilla 6y ago
    by making mistakes and making efforts to get better. Reading stuff by smarter people too helped.
mindcrime 6y ago
I don't know if something is wrong with me, but I simply cannot "decompose" a single feature into 500 different sub-task Jiras. No, nothing is wrong with you. But let me note that the Agile Manifesto doesn't say anything about Jira, or anything prescriptive about how small to make your stories. If your methodology asks you to do that, I'd argue that your methodology is broken. But it's broken because it's shit, not because it's "agile."
- polotics 6y ago
  Well "individuals and interactions over process and tools" is in the Manifesto, so I would say JIRA is implicitly covered. I am being asked to do "proper structured agile" by writing up many JIRA tasks in advance of learning what best to write, and I find it funny. It's not the disease though, just a symptom of having too many nonprogrammers around. Will resolve itself.
  - mindcrime 6y ago
    I am being asked to do "proper structured agile" by writing up many JIRA tasks in advance of learning what best to write, and I find it funny Yeah, it's hilarious how people are being told to do something in the name of "Agile" that is almost completely opposite of the spirit of the Agile Manifesto. sigh
    - deleted 6y ago
      [deleted]
  - BigJono 6y ago
    > just a symptom of having too many nonprogrammers around. Will resolve itself. Parkinson's Law doesn't get enough of the blame for bad dev environments. It's so easy to feel like you're doing 40 hours of difficult, important work a week, while actually accomplishing fuck all at best (or generating more work overall at worst). I bet a big chunk of the problems raised in this thread don't exist if everyone experiencing them cuts their team size in half.
ebiester 6y ago
This is not a question of agile or not. This is software estimation and design. To be able to decompose a feature, you need to learn how to build the software in your head before you go to paper. Consider a large billing page, for example. Step 1 is to look at the front end. What components do I need to build? (React might use components, or a set of partials and templates in rails, for example.) So, then, I know I need X subtasks, where I will build the pieces I need to expose that behavior to the client to start. I then look down into the backend. That might be a simple task on the backend, or given 20 minutes of looking, I might see problems that I'll need to tackle. The problems are their own subtasks. I may be able to group some of the front end to a single back end ticket, or I might need a separate subtask for each. Now, I'm likely to miss something. However, that's why this is an estimate rather than a concrete task list. It's to get started so that we know, at minimum, what it's going to take. It's not necessarily simple, but it is a skill that can be developed.
- wvenable 6y ago
  > To be able to decompose a feature, you need to learn how to build the software in your head before you go to paper. Even easier than building the software in your head is actually building the software. I often don't know what the shape of the problem is until I've built something. The users often don't know what they want until they've seen something. The failure of Agile as implemented is that it's still all about extensive meetings and planning. Software is not like building a bridge where you write out the blueprints and the expensive part is then building the bridge. Software is the blueprint. To be truly agile is to be able to get software features and changes running and out to users as quickly as possible. You can never get all the information -- if users could provide the details absolutely necessary to build the software on day one then they'd be the programmers. Being experienced helps you naturally scope problems but you'll still be wrong from time time. Being able to iterate on users feedback and dealing with your own failed assumptions is the key.
  - seangrogg 6y ago
    > I often don't know what the shape of the problem is until I've built something. This is the majority of estimation failures as far as I've seen. You can only "estimate" so far and then leave significant padding for all the other minutia that will likely creep in.
grobins2 6y ago
You're not the only one. My team and most teams in my company made the conscious decision to not use subtask.
alistairSH 6y ago
But maybe I'm just dumb. No, not at all. Decomposing a new feature into digestible pieces is hard work and a skill that is learned over time. It's also a skill to know when something is small-enough, or has enough unknowns that further decomposition is wasteful. Good product owners and managers know this and are good at it themselves. And the decomposition is typically at a story level - "can we take story X, break it into 2 smaller stories, and still deliver something of value?" The tasks are usually pretty self-evident once you break down the stories a few times. For a lot of my work, if the story is "As a user, I need to do X" the tasks are simply broken into distinctly testable pieces.* Is there a database change? That's a task. Is there an API change? That's another task. Front-end change? Third task. And if you get half-way through and need to start over, that's life and it happens reasonably often. Yeah, there might be some re-testing. Or, a new story for next sprint. It's up to me, as the manager, to make sure the stakeholders are informed and on-board. At the end of the day, as long as the team is making progress, I'm happy. And if the team isn't making progress, it's probably my fault (and almost never the fault of an individual contributor). * In my world, tasks don't exist in isolation. They're all subordinate to a user story. Every task (piece of work) we do is done in the furtherance of a well-defined need of the user. And developers are never defining tasks on their own - it's done as a team.
stickfigure 6y ago
It sounds like you're trying to decompose software into developer tasks, which is not what (my interpretation of) agile is about. Forget the developer for a moment and take the user perspective. What's the first thing the user wants to do? Log in? Ok, that's a story. What's the next thing the user wants to do? See a list of widget prices? Ok, that's a story. What's the next thing the user wants to do? Change a price? Story. If you can't sit down and think of a dozen narratives like this, then the fundamental problem that you don't really understand how people are supposed to use your software or what your software is supposed to do.
- loopz 6y ago
  Actually, those are stories developers tell themselves, not users!
- CyberDildonics 6y ago
  Calling everything a 'story' is just another in a long line of trends that pretend making up a new name for something is progress. (Also a user doesn't actually want to log in, they want to do something and you are making them log in)
- jussij 6y ago
  I would think if 'login' was simple enough to write as a single story then that login feature would be next to useless. The task of login is more about security, access control, authorization and tracking, not just giving the user access to a web landing page. That level of complexity makes it a project in itself.
  - stickfigure 6y ago
    That depends on business requirements. In simple cases, auth can be as simple as dropping a little javascript on the page. But sure, you can have follow-on stories like "user is denied access protected resource" or "admin sees resources accessed by user". Enough individually-useless stories and you end up with a useful app. That's kind of the point of agile.
ben509 6y ago
To some extend, you could if you worked on the task and, as you worked, said, "what am I doing now and what do I need to do next?" and then plugged that into something. It wouldn't be a complete decomposition, of course, a person watching would see your thinking unfold. I think speculative decomposition would be very interesting, especially in retrospective if we could see the rabbit holes we went down. Decomposing is easy since we naturally have to do that as we work. Heck, those 500 tasks are probably in your shell, browser and commit histories, mixed in with a bunch of other junk. The problem is tools like Jira make this heavy-weight, doing it up front makes it nigh impossible, and having others review all this stuff and it becoming promises blows up the LOE significantly. And, I don't think I'd want to be under that much of a microscope as I work. But if it were very lightweight, where I'm just posting my thoughts and can see them as a quick dependency diagram, and maybe attach notes, commits and URLs to them, and other people can see them, that'd be pretty helpful.
- Jtsummers 6y ago
  > But if it were very lightweight, where I'm just posting my thoughts and can see them as a quick dependency diagram, and maybe attach notes, commits and URLs to them, and other people can see them, that'd be pretty helpful. That's precisely the objective of "user stories" and other things. You write a high level version, put it in a backlog with priorities. When you get to it, you realize it's bigger than anticipated ("Oh, I can't just do X, I have to do A, B, and C."). So you turn X into three things, one of which you work on now, and the others in the backlog. Repeat until done. I don't think Jira is necessarily too heavy-weight, it's the way everyone seems to use it. They want to assign the tasks now, not treat them as backlog items or things that can be modified in the future. Which pushes them back towards big-design-up-front and entirely defeats the objective, you're back to low throughput, high latency development.
Swizec 6y ago
Software is like gardening https://blog.codinghorror.com/tending-your-software-garden/ https://blog.codinghorror.com/tending-your-software-garden/ The reality is that your ability to break things down depends on experience. I’ve built so many landing pages, for example, that I can tell you an exact breakdown of tasks. Been a part of so many SaaSes, I can tell you exactly what non-core features you’ll need, when, and how much work they are. I can also predict where you’ll hiccup. But ask me to build something new that’s never been done before (at least by me) and the most I can do is shrug and guess. Maybe give you a rough sketch of an outline of subtasks.
wpietri 6y ago
Yeah, I think trying to perfectly describe the work in advance is Waterfall thinking. Most of what gets sold as "Agile" these days is Waterfall dressed up in Agile terms. But as an example of early Agile intent, here is how we worked in 2004: http://williampietri.com/writing/2004/teamroom/ http://williampietri.com/writing/2004/teamroom/ You'll note that we never did detailed planning more than a week in advance. We could have, but it would have been a waste, because it would have been speculation on speculation. Instead we'd agree on something small to build, get it working, and then see what we thought.
mmcnl 6y ago
That's not agile, that's waterfall. With my team, I usually have just 2 or 3 "stories" that are taken up during a sprint. The rest is up to the development team. Works quite well. No one's asking to create dozens of tasks. A rough outline of what we're trying achieve combined with a high-level overview of what we think would need to be done is usually enough to get started in a sprint. If we fail, we fail, no one gets mad. That's agile if you ask me.
- sdiupIGPWEfh 6y ago
  The likes of SAFe argue otherwise, having you plan out and commit to _three month's_ worth of stories in advance. It's supposedly still "agile" because the plans you've "committed to" are expected to change as you go. Oh, and it's set up such that other teams are expecting to be able to depend on your team delivering stories by the sprints you said they'd be done, of course. No problem, as those dependencies probably existed anyway and now they're made explicit and public. As long as you've delivered the increment of work you'd promised when the three months are up, nobody gets fired. Totally agile.
danielrhodes 6y ago
You're right that there is a limit to the usefulness of breaking down sub-tasks. It's up to a team how granular they get. Here is why it is important: a) Risk management - if you break a feature down into sub-tasks at any granularity, you are creating an agreement (or at least a conversation) among your peers that this is how something will be implemented, and digging in beforehand to uncover areas which might impede shipping the feature sooner. b) You're going to have to break down the feature at some point. Being able to think through this ahead of time can be challenging, but often times is the meat of the work you do. You have to get into the hang of it -- think top-down or bottom-up ways of approaching it. But what if you don't have enough information or understanding yet to do that? Agile is not great for these tasks where you need to take some time learning or experimenting. I would offer you a couple extra tools here: - A "spike" ticket -- Agile is all about deliverables and commitments, but sometimes that doesn't work. So create a spike ticket, and define what it is you want to investigate. If you deliver something, great! If not, no worries. The important part is that in the future you've done work that enabled you to learn how to estimate or break down that task in the future. - A time-boxed ticket -- similar to the spike, but you just make sure you don't spend more than an allotted time on a task.
- Rapzid 6y ago
  Spiking is great as just a general development process even if you don't have tickets/time-boxed items just for them. For example in Basecamp's "Shape Up" process spiking may be an initial uphill technique used to suss out the rest of the cycle's work and uncover all the hidden issues. Basically, you blaze a trail to the most disgusting, kluge-y, and otherwise slapdash implementation that validates your assumptions and satisfies your constraints while making note of everything that needs further work. That lets you bail early if some unknown issue will block success given the current criteria and constraints, and sets you up with the a list of the 80/20 work required to deliver the completed project.
jtdev 6y ago
Creating a huge list of tasks is actually what I would call an Agile anti-pattern. It's something that I unfortunately see all the time. User stories are meant to be written from a business or end-user perspective. It's a high level description of what is to be done, for who, and why, not how. I personally don't even like having tasks on the board, just give me a well written story and I'm happy to complete it based on what's written in the acceptance criteria.
- barrkel 6y ago
  How would you implement a database, or operating system, without a big list of tasks? Some things need to be designed, and don't work terribly well if they're evolved incrementally from user-visible features. Incremental additions can be, but there's also a risk of gradually degrading the architecture of a system through risk-minimized local changes by interchangable resources, I mean developers - which is what I generally see occur under Scrum.
Buttons840 6y ago
Is it a case of too many cooks in the kitchen? Company and developers are busy and successful, so they hire more, which continues until they are no longer successful. They remain busy, however, progress on the product is roughly constant. All the additional work capacity is spent on meetings and otherwise organizing the increased worker count. I believe the above describes every situation in which I have been asked to break down Jira tasks into unnaturally small tasks.
rezendi 6y ago
I wrote this, so I'm obviously biased, but: https://techcrunch.com/2018/12/09/jira-is-an-antipattern/ https://techcrunch.com/2018/12/09/jira-is-an-antipattern/
FridgeSeal 6y ago
I have the same issue! Maybe it was just my particular job, but so much of my work was figuring out how to do xyz, so it was hard to give estimates for something whilst I was still figuring out the scope and complexity of along with how it even works and I was rarely, if ever doing the same/similar thing multiple times. Whenever project managers did push for me to break things down further they’d then immediately complain about too much technical detail.

virgil_disgr4ce 6y ago

> but I have to iterate on features holistically and sometimes speculatively. YES. THANK YOU! I've been trying to tell people this for ages. Maybe other people are somehow capable of perfectly predicting every conceivable edge-case and consequence without even starting to work on something, but I can't. I have to start building something in order to see it clearly. And this ENRAGES certain kinds of managers, I have found.

deleted 6y ago
[deleted]
anon9001 6y ago
Managers just want you to deliver on a predictable schedule. Here's how you can solve your problem: Make as many tickets as you can think of, it doesn't really matter if they contain the essence of the problem or not, it just matters that there are many tickets associated with the task. Once you have your tickets, estimate them with as much padding as possible. If the manager complains that you're padding a ticket too much, make two tickets and split the estimate. Once you have a big pile of tickets and estimates, you've bought yourself enough time to do the work. Go do the work, then mark all the tickets as complete. You'll figure out the edge cases as you go, as long as you've made enough tickets and time to do the job at a reasonable pace. If you have extra time left over, get started on the next thing, improve your tooling, or try to help someone else with their tasks. If you don't have extra time left over, make more tickets next time.
- james-mcelwain 6y ago
  This is also what I do, but it seems so antagonistic and deceptive. I want my relationship with my PM to be productive and collaborative.
- gilbetron 6y ago
  Managers want a fiction to present to their superiors - the most happy my managers are is when what you describe happens. I like your approach :) I might have to be more explicit in creating a fiction. The only issue is if/when you actually run into things that significantly delay things right towards the end.
- alistairSH 6y ago
  Ack, please don't. As a manager, I'm pretty sure I'd see this as the bullshit it is and call you on it. We're not all morons.
  - anon9001 6y ago
    Where exactly is the problem with my strategy? I'm also a manager of a small team. My main goals are to make sure everyone is not idle, not burned out, and not missing deadlines. My boss's goal is to try and get everyone to work every waking hour so we can deliver faster. My job is primarily to keep the peace between the executives and the workers. When I fail the workers, it looks like unpaid overtime. When I fail the executives, it looks like undelivered features. I think the actual purpose of agile, from a developer's perspective, is to create more time to deliver quality engineering work product. From an executive's perspective, agile exists to squeeze developers into completing tickets faster. As a manager, it's my job to keep both parties as satisfied as possible. If engineers have enough time to build and executives get enough deliverables, then the company succeeds. What's your strategy?
    - alistairSH 6y ago
      I read your comment as "create as many tickets as necessary to throw off management's understanding of the effort and complexity of the problem." Creating more tasks than necessary sounds like a waste of everybody's time. As I noted in a parallel comment, on my team, developers are never creating tasks on their own or in a vacuum. It's done as a team effort during planning meetings. Perhaps I should add that my boss (senior director) has never asked me about my board, velocity, or anything like that. Discussion is higher level - "is project X on schedule?" or "are you going to miss anything on your roadmap?" not "why is task X or story Y not done yet?" If your director is asking that, he has too much time on his hands.

GrumpyYoungMan 6y ago

> "I simply cannot "decompose" a single feature into 500 different sub-task Jiras." Nobody can; that's the primary failure mode of waterfall. Anybody who is telling you to decompose a feature into that many subtasks might claim to be doing agile but they really are trying to do waterfall.

deleted 6y ago
[deleted]
mumblemumble 6y ago
> that's the primary failure mode of waterfall That's the primary failure mode of a straw man software development methodology called waterfall that Scrum practitioners like to use as a bogeyman to appeal to for rhetorical purposes during the inevitable arguments about niggly little details of how to implement Scrum during sprint retrospectives. I've never actually done real waterfall, but I did study it way back when I was in college, and I have worked in government contracts, which tend to handle the work in a way that is similar to the waterfall I read about in school. One thing I distinctly remember is that it was designed to be a flexible and iterative methodology that would have been difficult to cram into a ticketing system in the first place, let alone cram into Jira while simultaneously carving the work into tiny pieces, up front, all at once. FWIW, the only place I've ever been asked to do something like that is in ostensible Scrum shops. In fact, the only time I've ever seen anything that looks like the Waterfall of scrum lore is in shops that are trying to do Scrum. I am beginning to suspect that the Waterfall of Scrum lore isn't actually a thing that happens outside of Scrum at all. It's actually what naturally tends to emerge when you try to apply Scrum methodology in a situation where something along the lines of the real, textbook waterfall model would have been more appropriate. As a concrete example, I currently work at a team that ostensibly uses Scrum, but where QA is a separate department with its own practices that the dev team does not control. They do still want some ability to anticipate work that's coming their way, though, so they're monitoring the scrum board for that purpose. This is the moment where it gets messy, because we're then asked to document things ahead of time, and it's a minor crisis if we keep it flexible during the sprint because any changes to the set of tickets becomes an inevitable hassle as they complain that we've screwed up work product that they generate based on those tickets. It's absolutely something straight out of waterfall horror stories from Scrum lore. But it's only happening because we're doggedly insisting on something that's at least cosmetically similar to scrum. If we weren't doing that, we'd be freer to choose modes of interaction and business artifacts that are better suited to the reality we occupy.

goalieca 6y ago

No, you're not dumb. Telling someone precisely how to work and then tracking every bit of it is called micro-management.

danieldisu 6y ago

Don't get me started when they try to push all clients into one jira, each one of them with their own complexities, release cycles etc. Or when they try to measure team effectiveness using Jira un some way or another, every team is capable of doing more Jiras in the same time by just splitting them more!

anthonyrstevens 6y ago

Nobody can. But anybody can ask "What is the next task that needs to be done?"

loopz 6y ago
So building constructions blindfolded is the norm? Sounds like recipe for entangled messes. It has always been at systems thinking, design and architecture, in that order. Doing it organically is a magic feat rarely done well.

HeyLaughingBoy 6y ago

It can usually be done. The problem is that people assume that now that you have that list of subtasks, you can iterate through them one at a time until you've built the feature. That's the major disconnect. What I do with my guys is I make them decompose the feature, but with the understanding that they'll probably be jumping from one subtask to the other, back and forth, as they understand what it is they'll be building. AND they'll probably come across new subtasks as they work through the feature. It makes Jira look crappy, but it Reflects Reality (tm) which to me is far more important than keeping Jira clean.

Ididntdothis 6y ago
That's how it works. Touch something here, touch something there, learn from it and slowly build up the whole thing. I think Scrum and Kanban may work if you have a somewhat mature system where you add incremental features but if you do something relatively new and big the backlog can not reflect reality. Or it forces a workflow that doesn't make sense. I have seen it multiple times where people refused to make changes to something because their story was done already. Never mind that the design turned out to be unsuitable.
- mark-r 6y ago
  I saw this happen before Agile was even a thing. The possibility of a bug in the spec was never a consideration. You had to hope your assumptions going in were correct, or your users were screwed.
  - HeyLaughingBoy 6y ago
    A story I love to tell is the time where I was in the medical device industry. A requirement was formally reviewed with the owner and he signed off on it. The design was completed and reviewed and found to match the requirement, I implemented it, tested it and found it worked as expected and handed off to QA. QA tested it and verified that it correctly implemented the Requirement. The feature was turned over to its owner for so he could use it and his response was "that's not what I asked for!"

gdilla 6y ago

What I find helpful as a product manager, I discuss each feature with engineers - and we collaboratively break it down into a bare-bones "MVP" version, but consider nice to haves as future stuff or TBD based on what we learn. That helps push scope down and manage holistic iteration. Every feature should have an MVP version of it. At least asking the question can help break down that first user story.

texasbigdata 6y ago
How did you learn this?
- burner831234 6y ago
  I learned it through the job. I think thats the quiet secret. Engineering is best learned through a form of apprenticeship but so is product.
  - loopz 6y ago
    Too bad corps optimize away apprenticeship, and then wonder why their processes delivers less and less...
- gdilla 6y ago
  by making mistakes and making efforts to get better. Reading stuff by smarter people too helped.

mindcrime 6y ago

I don't know if something is wrong with me, but I simply cannot "decompose" a single feature into 500 different sub-task Jiras. No, nothing is wrong with you. But let me note that the Agile Manifesto doesn't say anything about Jira, or anything prescriptive about how small to make your stories. If your methodology asks you to do that, I'd argue that your methodology is broken. But it's broken because it's shit, not because it's "agile."

polotics 6y ago
Well "individuals and interactions over process and tools" is in the Manifesto, so I would say JIRA is implicitly covered. I am being asked to do "proper structured agile" by writing up many JIRA tasks in advance of learning what best to write, and I find it funny. It's not the disease though, just a symptom of having too many nonprogrammers around. Will resolve itself.
- mindcrime 6y ago
  I am being asked to do "proper structured agile" by writing up many JIRA tasks in advance of learning what best to write, and I find it funny Yeah, it's hilarious how people are being told to do something in the name of "Agile" that is almost completely opposite of the spirit of the Agile Manifesto. sigh
  - deleted 6y ago
    [deleted]
- BigJono 6y ago
  > just a symptom of having too many nonprogrammers around. Will resolve itself. Parkinson's Law doesn't get enough of the blame for bad dev environments. It's so easy to feel like you're doing 40 hours of difficult, important work a week, while actually accomplishing fuck all at best (or generating more work overall at worst). I bet a big chunk of the problems raised in this thread don't exist if everyone experiencing them cuts their team size in half.

ebiester 6y ago

This is not a question of agile or not. This is software estimation and design. To be able to decompose a feature, you need to learn how to build the software in your head before you go to paper. Consider a large billing page, for example. Step 1 is to look at the front end. What components do I need to build? (React might use components, or a set of partials and templates in rails, for example.) So, then, I know I need X subtasks, where I will build the pieces I need to expose that behavior to the client to start. I then look down into the backend. That might be a simple task on the backend, or given 20 minutes of looking, I might see problems that I'll need to tackle. The problems are their own subtasks. I may be able to group some of the front end to a single back end ticket, or I might need a separate subtask for each. Now, I'm likely to miss something. However, that's why this is an estimate rather than a concrete task list. It's to get started so that we know, at minimum, what it's going to take. It's not necessarily simple, but it is a skill that can be developed.

wvenable 6y ago
> To be able to decompose a feature, you need to learn how to build the software in your head before you go to paper. Even easier than building the software in your head is actually building the software. I often don't know what the shape of the problem is until I've built something. The users often don't know what they want until they've seen something. The failure of Agile as implemented is that it's still all about extensive meetings and planning. Software is not like building a bridge where you write out the blueprints and the expensive part is then building the bridge. Software is the blueprint. To be truly agile is to be able to get software features and changes running and out to users as quickly as possible. You can never get all the information -- if users could provide the details absolutely necessary to build the software on day one then they'd be the programmers. Being experienced helps you naturally scope problems but you'll still be wrong from time time. Being able to iterate on users feedback and dealing with your own failed assumptions is the key.
- seangrogg 6y ago
  > I often don't know what the shape of the problem is until I've built something. This is the majority of estimation failures as far as I've seen. You can only "estimate" so far and then leave significant padding for all the other minutia that will likely creep in.

grobins2 6y ago

You're not the only one. My team and most teams in my company made the conscious decision to not use subtask.

alistairSH 6y ago

But maybe I'm just dumb. No, not at all. Decomposing a new feature into digestible pieces is hard work and a skill that is learned over time. It's also a skill to know when something is small-enough, or has enough unknowns that further decomposition is wasteful. Good product owners and managers know this and are good at it themselves. And the decomposition is typically at a story level - "can we take story X, break it into 2 smaller stories, and still deliver something of value?" The tasks are usually pretty self-evident once you break down the stories a few times. For a lot of my work, if the story is "As a user, I need to do X" the tasks are simply broken into distinctly testable pieces.* Is there a database change? That's a task. Is there an API change? That's another task. Front-end change? Third task. And if you get half-way through and need to start over, that's life and it happens reasonably often. Yeah, there might be some re-testing. Or, a new story for next sprint. It's up to me, as the manager, to make sure the stakeholders are informed and on-board. At the end of the day, as long as the team is making progress, I'm happy. And if the team isn't making progress, it's probably my fault (and almost never the fault of an individual contributor). * In my world, tasks don't exist in isolation. They're all subordinate to a user story. Every task (piece of work) we do is done in the furtherance of a well-defined need of the user. And developers are never defining tasks on their own - it's done as a team.

stickfigure 6y ago

It sounds like you're trying to decompose software into developer tasks, which is not what (my interpretation of) agile is about. Forget the developer for a moment and take the user perspective. What's the first thing the user wants to do? Log in? Ok, that's a story. What's the next thing the user wants to do? See a list of widget prices? Ok, that's a story. What's the next thing the user wants to do? Change a price? Story. If you can't sit down and think of a dozen narratives like this, then the fundamental problem that you don't really understand how people are supposed to use your software or what your software is supposed to do.

loopz 6y ago
Actually, those are stories developers tell themselves, not users!
CyberDildonics 6y ago
Calling everything a 'story' is just another in a long line of trends that pretend making up a new name for something is progress. (Also a user doesn't actually want to log in, they want to do something and you are making them log in)
jussij 6y ago
I would think if 'login' was simple enough to write as a single story then that login feature would be next to useless. The task of login is more about security, access control, authorization and tracking, not just giving the user access to a web landing page. That level of complexity makes it a project in itself.
- stickfigure 6y ago
  That depends on business requirements. In simple cases, auth can be as simple as dropping a little javascript on the page. But sure, you can have follow-on stories like "user is denied access protected resource" or "admin sees resources accessed by user". Enough individually-useless stories and you end up with a useful app. That's kind of the point of agile.

ben509 6y ago

To some extend, you could if you worked on the task and, as you worked, said, "what am I doing now and what do I need to do next?" and then plugged that into something. It wouldn't be a complete decomposition, of course, a person watching would see your thinking unfold. I think speculative decomposition would be very interesting, especially in retrospective if we could see the rabbit holes we went down. Decomposing is easy since we naturally have to do that as we work. Heck, those 500 tasks are probably in your shell, browser and commit histories, mixed in with a bunch of other junk. The problem is tools like Jira make this heavy-weight, doing it up front makes it nigh impossible, and having others review all this stuff and it becoming promises blows up the LOE significantly. And, I don't think I'd want to be under that much of a microscope as I work. But if it were very lightweight, where I'm just posting my thoughts and can see them as a quick dependency diagram, and maybe attach notes, commits and URLs to them, and other people can see them, that'd be pretty helpful.

Jtsummers 6y ago
> But if it were very lightweight, where I'm just posting my thoughts and can see them as a quick dependency diagram, and maybe attach notes, commits and URLs to them, and other people can see them, that'd be pretty helpful. That's precisely the objective of "user stories" and other things. You write a high level version, put it in a backlog with priorities. When you get to it, you realize it's bigger than anticipated ("Oh, I can't just do X, I have to do A, B, and C."). So you turn X into three things, one of which you work on now, and the others in the backlog. Repeat until done. I don't think Jira is necessarily too heavy-weight, it's the way everyone seems to use it. They want to assign the tasks now, not treat them as backlog items or things that can be modified in the future. Which pushes them back towards big-design-up-front and entirely defeats the objective, you're back to low throughput, high latency development.

Swizec 6y ago

Software is like gardening https://blog.codinghorror.com/tending-your-software-garden/ https://blog.codinghorror.com/tending-your-software-garden/ The reality is that your ability to break things down depends on experience. I’ve built so many landing pages, for example, that I can tell you an exact breakdown of tasks. Been a part of so many SaaSes, I can tell you exactly what non-core features you’ll need, when, and how much work they are. I can also predict where you’ll hiccup. But ask me to build something new that’s never been done before (at least by me) and the most I can do is shrug and guess. Maybe give you a rough sketch of an outline of subtasks.

wpietri 6y ago

Yeah, I think trying to perfectly describe the work in advance is Waterfall thinking. Most of what gets sold as "Agile" these days is Waterfall dressed up in Agile terms. But as an example of early Agile intent, here is how we worked in 2004: http://williampietri.com/writing/2004/teamroom/ http://williampietri.com/writing/2004/teamroom/ You'll note that we never did detailed planning more than a week in advance. We could have, but it would have been a waste, because it would have been speculation on speculation. Instead we'd agree on something small to build, get it working, and then see what we thought.

mmcnl 6y ago

That's not agile, that's waterfall. With my team, I usually have just 2 or 3 "stories" that are taken up during a sprint. The rest is up to the development team. Works quite well. No one's asking to create dozens of tasks. A rough outline of what we're trying achieve combined with a high-level overview of what we think would need to be done is usually enough to get started in a sprint. If we fail, we fail, no one gets mad. That's agile if you ask me.

sdiupIGPWEfh 6y ago
The likes of SAFe argue otherwise, having you plan out and commit to _three month's_ worth of stories in advance. It's supposedly still "agile" because the plans you've "committed to" are expected to change as you go. Oh, and it's set up such that other teams are expecting to be able to depend on your team delivering stories by the sprints you said they'd be done, of course. No problem, as those dependencies probably existed anyway and now they're made explicit and public. As long as you've delivered the increment of work you'd promised when the three months are up, nobody gets fired. Totally agile.

danielrhodes 6y ago

You're right that there is a limit to the usefulness of breaking down sub-tasks. It's up to a team how granular they get. Here is why it is important: a) Risk management - if you break a feature down into sub-tasks at any granularity, you are creating an agreement (or at least a conversation) among your peers that this is how something will be implemented, and digging in beforehand to uncover areas which might impede shipping the feature sooner. b) You're going to have to break down the feature at some point. Being able to think through this ahead of time can be challenging, but often times is the meat of the work you do. You have to get into the hang of it -- think top-down or bottom-up ways of approaching it. But what if you don't have enough information or understanding yet to do that? Agile is not great for these tasks where you need to take some time learning or experimenting. I would offer you a couple extra tools here: - A "spike" ticket -- Agile is all about deliverables and commitments, but sometimes that doesn't work. So create a spike ticket, and define what it is you want to investigate. If you deliver something, great! If not, no worries. The important part is that in the future you've done work that enabled you to learn how to estimate or break down that task in the future. - A time-boxed ticket -- similar to the spike, but you just make sure you don't spend more than an allotted time on a task.

Rapzid 6y ago
Spiking is great as just a general development process even if you don't have tickets/time-boxed items just for them. For example in Basecamp's "Shape Up" process spiking may be an initial uphill technique used to suss out the rest of the cycle's work and uncover all the hidden issues. Basically, you blaze a trail to the most disgusting, kluge-y, and otherwise slapdash implementation that validates your assumptions and satisfies your constraints while making note of everything that needs further work. That lets you bail early if some unknown issue will block success given the current criteria and constraints, and sets you up with the a list of the 80/20 work required to deliver the completed project.

jtdev 6y ago

Creating a huge list of tasks is actually what I would call an Agile anti-pattern. It's something that I unfortunately see all the time. User stories are meant to be written from a business or end-user perspective. It's a high level description of what is to be done, for who, and why, not how. I personally don't even like having tasks on the board, just give me a well written story and I'm happy to complete it based on what's written in the acceptance criteria.

barrkel 6y ago
How would you implement a database, or operating system, without a big list of tasks? Some things need to be designed, and don't work terribly well if they're evolved incrementally from user-visible features. Incremental additions can be, but there's also a risk of gradually degrading the architecture of a system through risk-minimized local changes by interchangable resources, I mean developers - which is what I generally see occur under Scrum.

Buttons840 6y ago

Is it a case of too many cooks in the kitchen? Company and developers are busy and successful, so they hire more, which continues until they are no longer successful. They remain busy, however, progress on the product is roughly constant. All the additional work capacity is spent on meetings and otherwise organizing the increased worker count. I believe the above describes every situation in which I have been asked to break down Jira tasks into unnaturally small tasks.

rezendi 6y ago

I wrote this, so I'm obviously biased, but: https://techcrunch.com/2018/12/09/jira-is-an-antipattern/ https://techcrunch.com/2018/12/09/jira-is-an-antipattern/

FridgeSeal 6y ago

I have the same issue! Maybe it was just my particular job, but so much of my work was figuring out how to do xyz, so it was hard to give estimates for something whilst I was still figuring out the scope and complexity of along with how it even works and I was rarely, if ever doing the same/similar thing multiple times. Whenever project managers did push for me to break things down further they’d then immediately complain about too much technical detail.