15 ms·

> And so people take tickets, implement them as written, pass them off to whoever is next in the workflow, consider their job well done, even if working on scat

> And so people take tickets, implement them as written, pass them off to whoever is next in the workflow, consider their job well done, even if working on scattered groups of them in parallel might be much more effective … and without ever considering the larger goal. “Implement the Upload button” says the ticket; so that is all that is done. The ticket does not explain that the larger goal of the Upload button is to let users back up their work. Jira was designed for agile software development like Scrum, so you should write user stories, not mini specifications. 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. That way, you get the context that the article is bemoaning the lack of, and the developer might even think "Hey, I know company $XY has an API for getting the report data, wouldn't it be even easier if we fetched it directly?" And in a good agile process, you'd discuss this with the product owner, and rewrite the story to "As a user, I want data from $XY company in my system with minimal effort" or something like that. No tool can substitute a good development process, and good communication between the involved parties. That said, Jira does have it downsides, and not tracking dependencies very well is one of them. And then there are things that can be downsides, but don't need to be. It's so flexible that many shops configure it to be pretty much unusable, but others create workflows that work very well.

hellofunk 8y ago
>"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", This is a more general user story than I've seen when I've worked in agile developments. Usually, the stories are quite specific, like "As a user, I can click an Upload button to provide an Excel report."
- mcbutterbunz 8y ago
  I agree. Usually the stories I've seen written are very implementation specific rather than an expression of the desired state. I believe its because its easier to think about concrete solutions. This goes for product owners and devs alike.
SpicyLemonZest 8y ago
The problem is that tracking dependencies is a critical part of most software development. For example, the "import reports from $XY" story really needs to have a consistent user experience with the "import data from $AB" story. if I can't express that dependency in the tool, I have no choice but to write down the $AB workflow as a specification for the $XY ticket.
- skybrian 8y ago
  I think the theory is to do a simple end-to-end implementation for $xy and then redo the UI when you add $ab. Or the other way around, if the customer wants $ab first. So the dependency isn't a static thing, it depends on prioritization of the user-facing features. Implicit in this is the assumption that you're not scared of redoing the internals or redesigning the UI as you add features.
  - lugg 8y ago
    Scared of? Sometimes that incurs designer and translation costs. It's not about changing the interface frequently. It's about changing it poorly.
    - skybrian 8y ago
      Well, they're closely related. If you have a designer on the team, don't have translations (yet) and it's easy to back out a change, mistakes aren't that big a deal, and everything is easier, faster, and more fun. But as churn gets more expensive (and this is sometimes inevitable), you want to try harder to avoid it. A process is only agile while revisions are cheap. It seems like a lot of arguments could be avoided if it were more widely understood that this is a trade-off, with agility on one end and stability on the other, and stability is often good. Particularly when a lot of people depend on you.
      - lugg 8y ago
        Agreed, but you tried to make me sound like a pussy for understanding that tradeoff. "Unless you're scared of a little moving fast and breaking things."
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.
augbog 8y ago
I agree with a lot of these things -- although I will say it took us a lot of time and the right people to help SET UP JIRA to be able to work with our process.
- Drdrdrq 8y ago
  This. Setting up Jira invariably meant searching internet for me. I have seldom worked with less intuitive UI (Outlook comes to mind, but it is a much smaller app). In light of this article - is it because noone had a clear vision of the app and they all just implemented tickets?
  - angry_octet 8y ago
    Sounds like they had no process to begin with, found a ticket tracking tool, made fulfilling tickets their process, and now blame the tool.
  - TheGRS 8y ago
    That's kind of funny to think about. I'm pretty sure most of JIRA's configuration faults are from over-zealously fulfilling every wish their customers in the early-to-mid level stages had. I'm always confused by the "workflow screen" section and why it was ever done that way.
captain_crabs 8y ago
I haven't read any further comments on purpose, immediately logged in to reply because I have a prediction: People are going to say the user story you listed is _way_ too vague, general, or otherwise "not right" or "something they've never seen." They're going to reject it/pick it apart for a litany of reasons, all of which triangulated against their individual experiences. Me too! Here goes: I've found "user stories" miss entire dimensions of context from the business side which are incredibly important to developers. In lesser-performing orgs, this is often a way the "business folks" (and yes - in some orgs, there is a distinct divide) wield information asymmetry to pawn off blame onto devs when "things aren't right." This information about how people are really gonna use the software vanishes somewhere along the way before it turns into a user story. This post gets at the heart of it pretty well: https://jtbd.info/replacing-the-user-story-with-the-job-story-af7cdee10c27 https://jtbd.info/replacing-the-user-story-with-the-job-stor... (which, btw, if this makes sense to you, is something you're strangely passionate about, and you're not familiar with "jobs to be done" then go get intercom's free ebook on it right now) I have another guess. This is less of a prediction, more of a thing I'd like to find out: of all the people who reject your user story, how many of them have worked at places where their product manager isn't a technical person? My guess is: most of them. I'm also guessing PM's get super specific because developers moan at them over minutiae, info gets cut out/they don't realize it's important, and there you go. I'm betting most orgs adopt agile as a means of combating poor engineering dept performance, and generally (not all the time - but generally) this is directly due to the people managing the technical people not knowing what they're doing, so it's essentially a set of default behaviors that protect both sides and guarantees some minimum (read: not maximum) of performance. So these product managers who don't understand any development are put in charge of developers consider writing tickets their job, and instead of understanding reality -> reflecting that in tickets, they write their tickets and try to coerce reality to follow. Frankly, take a bunch of people who already didn't want to change their process, force them to hear "you should update your process that's how things are supposed to be" every day, and after a couple months they actually start to do it. Ticket shaping is super hard. I don't trust a non-technical PM to do it right, unless they happen to be experienced and/or have devs alongside them who are essentially just doing their job for them. Add onto this the fact that typically management consider all parts of software development a linear process. Not to say you can't have PM's who are nontechnical, and can bring all the right context/organize everyone in the right ways. I believe they exist, I just haven't worked with any. Devs are generally ineffective at communicating technical context in non-technical ways, and reality is an emergent mix of both business & technical. this has turned rambly. tl;dr - user stories are such a vague/overloaded concept for so many reasons, if you have the choice read up on "job stories" and try and switch to those. They're no less confusing to implement, but they force you to find answers to much better questions.
bloomca 8y ago
You can't share context indefinitely, so at some point you have to commit to a solution. E.g. "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" can transform into "As a user, I want data from $XY company in my system with minimal effort" during grooming or planning, but rarely during development (it is also possible, but it will break all your sprint commitments, and possibly other teams' commitments as well). Now, regarding the broader context. It depends on the project – the larger it is, the harder it is to share it. In a small project it is very simple to describe in user story why is it needed, what is the end goal, and link to some epic. In the large projects, however, it is much more tricky, and while their example is a little bit too much, but sometimes it will literally hurt the project to share too much (not from security perspective, just from the amount of information). Sometimes there is too much info, and only PM/PO/BA know enough to judge, and sometimes such story is too big, and you end up with it being an epic, and "Implement a button" is a user story. JIRA might work, and it works pretty well for many companies. From my experience, it is the best for middle sized companies – too much overhead for small companies, not detailed enough for too big companies.
jiveturkey 8y ago
true about weaknesses such as complex dependencies but you don’t have to use jira exclusively. it’s just a tool not an entire process.
theptip 8y ago
I was about to comment with the exact same quote. This is my main issue with the OP; if you're using Jira for tasks like "Implement the upload button" then of course your developers are going to lack context about the broader vision/roadmap. That sort of division of labor encourages "widget factory" thinking. This is not a problem with Jira, it's a problem with the underlying product planning process. I'm sure plenty of companies have "scrum masters", create Jira tickets called "stories", and think they are "doing Agile", while using a process like that. But that's seems like cargo-cult agile software development to me. I do agree with the narrower critique that it's hard to present a broader roadmap with Jira; I've found Portfolio to be only OK for managing sequencing of Jira epics without getting bogged down in the details of individual stories.
partycoder 8y ago
If you define and implement all user stories, in the end what you will have is: a functional prototype, not a product. A finished product can be sold ethically, a prototype cannot.
facorreia 8y ago
> And so people take tickets, implement them as written, pass them off to whoever is next in the workflow Sounds like a process problem and communication breakdown, not a JIRA issue. We use JIRA and it isn't like that at all.
antod 8y ago
> Jira was designed for agile software development like Scrum,... Alternative view: when agile software development features finally turned up for Jira, they still took a while to graduate from paid plugin (Greenhopper) to core features. To me "designed for" always felt like "tacked on", and that they were somewhat fighting existing legacy object models.
- FlyingAvatar 8y ago
  This. JIRA has been around over 15 years and definitely supported other workflows before it supported Agile ones specifically. To me, it has felt in need of a complete rewrite for probably half of that time. If you've had to do administration for it, or have had to dive into more complex configurations, it definitely feels like it's more baggage than product.
JohnBooty 8y ago
Jira was designed for agile software development like Scrum, so you should write user stories, not mini specifications. Yeah, this is true. I was at a company that did Scrum. There were two managers who functioned as product owners on the scrum teams. Manager A took the correct approach. Developers were aware of the overall goal, and we broke those goals down into stories, and broke the stories down into tasks. As developers we had a good sense of ownership and responsibility. Manager B tended to just issue stories (which were really mini specs) to us. We were treated like children. We didn't know why we were doing what we were doing, and were not able to contribute to the design of the solutions we were handed, which were often suboptimal. A lot of teams take "Manager B's" approach and wonder why the developers hate Scrum.
- rficcaglia 8y ago
  I love being manager A. I always start sprints/epics as manager A. In my experience 1 of 5 projects succeeds with Manager A and I get a very superior result with a solution I myself would have never thought of. Rainbows and unicorns everywhere! But...the other 4 times I get either no solution, or the Upload button only works as long as one user at a time tries it, or only on Chrome when all customers use IE8, or the documents randomly disappear when new dockers spin up, or the button needed to be WCAG compliant and no one bothered checking, etc. Suddenly I am forced to be Manager B and no one is happy. The feature is 3x over budget and 3 weeks late. What leading indicators can we use to predict or at least alert to a failing Manager A project early in the cycle so I can do what I love, devs can do what they love, biz stakeholders get things on time and on budget, and customers can get something they love?
  - JohnBooty 8y ago
    > 3 weeks late Whatever's going on, you gotta catch it sooner, right? Any way the stories can be smaller and get out to QA sooner? Maybe you could try being "Manager AB" Instead of a totally hands-off "Manager A" style maybe you can work more closely with them to develop those stories and make sure they understand what technical requirements (WCAG compliance, etc) each story needs to hit before they estimate them
dominotw 8y ago
> Jira was designed for agile software development like Scrum it says it was created in 2002
- swish_bob 8y ago
  Snowbird was 2001. That said, I remember using Jira before it had any understanding of an agile workflow, because part of my job was creating one in it.
rawoke083600 8y ago
lol scrum... what a wasted time those meetings were... pulling numbers out the air...
shliachtx 8y ago
> 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. I think that practically this often ends up being "As a user, I would like to have an upload button", Of course, adding "As a user" to the beginning of a sentence does not a user story make.
tynpeddler 8y ago
Don't write user stories. Many of the tasks that can be accomplished in a sprint aren't actually useful to users. In addition, stories aren't for users, they're for developers. The story, first and foremost, must be friendly enough to the developer that they can pick it up and work it. Instead, write user features. Let the developers write the stories. It took a while to convince my team of this (agile consultants can do a real number on people sometimes) but in the end, it let everyone write down and organize what they needed to, and it helped us organize all the work in a single hierarchy.

hellofunk 8y ago

>"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", This is a more general user story than I've seen when I've worked in agile developments. Usually, the stories are quite specific, like "As a user, I can click an Upload button to provide an Excel report."

mcbutterbunz 8y ago
I agree. Usually the stories I've seen written are very implementation specific rather than an expression of the desired state. I believe its because its easier to think about concrete solutions. This goes for product owners and devs alike.

SpicyLemonZest 8y ago

The problem is that tracking dependencies is a critical part of most software development. For example, the "import reports from $XY" story really needs to have a consistent user experience with the "import data from $AB" story. if I can't express that dependency in the tool, I have no choice but to write down the $AB workflow as a specification for the $XY ticket.

skybrian 8y ago
I think the theory is to do a simple end-to-end implementation for $xy and then redo the UI when you add $ab. Or the other way around, if the customer wants $ab first. So the dependency isn't a static thing, it depends on prioritization of the user-facing features. Implicit in this is the assumption that you're not scared of redoing the internals or redesigning the UI as you add features.
- lugg 8y ago
  Scared of? Sometimes that incurs designer and translation costs. It's not about changing the interface frequently. It's about changing it poorly.
  - skybrian 8y ago
    Well, they're closely related. If you have a designer on the team, don't have translations (yet) and it's easy to back out a change, mistakes aren't that big a deal, and everything is easier, faster, and more fun. But as churn gets more expensive (and this is sometimes inevitable), you want to try harder to avoid it. A process is only agile while revisions are cheap. It seems like a lot of arguments could be avoided if it were more widely understood that this is a trade-off, with agility on one end and stability on the other, and stability is often good. Particularly when a lot of people depend on you.
    - lugg 8y ago
      Agreed, but you tried to make me sound like a pussy for understanding that tradeoff. "Unless you're scared of a little moving fast and breaking things."

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.

augbog 8y ago

I agree with a lot of these things -- although I will say it took us a lot of time and the right people to help SET UP JIRA to be able to work with our process.

Drdrdrq 8y ago
This. Setting up Jira invariably meant searching internet for me. I have seldom worked with less intuitive UI (Outlook comes to mind, but it is a much smaller app). In light of this article - is it because noone had a clear vision of the app and they all just implemented tickets?
- angry_octet 8y ago
  Sounds like they had no process to begin with, found a ticket tracking tool, made fulfilling tickets their process, and now blame the tool.
- TheGRS 8y ago
  That's kind of funny to think about. I'm pretty sure most of JIRA's configuration faults are from over-zealously fulfilling every wish their customers in the early-to-mid level stages had. I'm always confused by the "workflow screen" section and why it was ever done that way.

captain_crabs 8y ago

I haven't read any further comments on purpose, immediately logged in to reply because I have a prediction: People are going to say the user story you listed is _way_ too vague, general, or otherwise "not right" or "something they've never seen." They're going to reject it/pick it apart for a litany of reasons, all of which triangulated against their individual experiences. Me too! Here goes: I've found "user stories" miss entire dimensions of context from the business side which are incredibly important to developers. In lesser-performing orgs, this is often a way the "business folks" (and yes - in some orgs, there is a distinct divide) wield information asymmetry to pawn off blame onto devs when "things aren't right." This information about how people are really gonna use the software vanishes somewhere along the way before it turns into a user story. This post gets at the heart of it pretty well: https://jtbd.info/replacing-the-user-story-with-the-job-story-af7cdee10c27 https://jtbd.info/replacing-the-user-story-with-the-job-stor... (which, btw, if this makes sense to you, is something you're strangely passionate about, and you're not familiar with "jobs to be done" then go get intercom's free ebook on it right now) I have another guess. This is less of a prediction, more of a thing I'd like to find out: of all the people who reject your user story, how many of them have worked at places where their product manager isn't a technical person? My guess is: most of them. I'm also guessing PM's get super specific because developers moan at them over minutiae, info gets cut out/they don't realize it's important, and there you go. I'm betting most orgs adopt agile as a means of combating poor engineering dept performance, and generally (not all the time - but generally) this is directly due to the people managing the technical people not knowing what they're doing, so it's essentially a set of default behaviors that protect both sides and guarantees some minimum (read: not maximum) of performance. So these product managers who don't understand any development are put in charge of developers consider writing tickets their job, and instead of understanding reality -> reflecting that in tickets, they write their tickets and try to coerce reality to follow. Frankly, take a bunch of people who already didn't want to change their process, force them to hear "you should update your process that's how things are supposed to be" every day, and after a couple months they actually start to do it. Ticket shaping is super hard. I don't trust a non-technical PM to do it right, unless they happen to be experienced and/or have devs alongside them who are essentially just doing their job for them. Add onto this the fact that typically management consider all parts of software development a linear process. Not to say you can't have PM's who are nontechnical, and can bring all the right context/organize everyone in the right ways. I believe they exist, I just haven't worked with any. Devs are generally ineffective at communicating technical context in non-technical ways, and reality is an emergent mix of both business & technical. this has turned rambly. tl;dr - user stories are such a vague/overloaded concept for so many reasons, if you have the choice read up on "job stories" and try and switch to those. They're no less confusing to implement, but they force you to find answers to much better questions.

bloomca 8y ago

You can't share context indefinitely, so at some point you have to commit to a solution. E.g. "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" can transform into "As a user, I want data from $XY company in my system with minimal effort" during grooming or planning, but rarely during development (it is also possible, but it will break all your sprint commitments, and possibly other teams' commitments as well). Now, regarding the broader context. It depends on the project – the larger it is, the harder it is to share it. In a small project it is very simple to describe in user story why is it needed, what is the end goal, and link to some epic. In the large projects, however, it is much more tricky, and while their example is a little bit too much, but sometimes it will literally hurt the project to share too much (not from security perspective, just from the amount of information). Sometimes there is too much info, and only PM/PO/BA know enough to judge, and sometimes such story is too big, and you end up with it being an epic, and "Implement a button" is a user story. JIRA might work, and it works pretty well for many companies. From my experience, it is the best for middle sized companies – too much overhead for small companies, not detailed enough for too big companies.

jiveturkey 8y ago

true about weaknesses such as complex dependencies but you don’t have to use jira exclusively. it’s just a tool not an entire process.

theptip 8y ago

I was about to comment with the exact same quote. This is my main issue with the OP; if you're using Jira for tasks like "Implement the upload button" then of course your developers are going to lack context about the broader vision/roadmap. That sort of division of labor encourages "widget factory" thinking. This is not a problem with Jira, it's a problem with the underlying product planning process. I'm sure plenty of companies have "scrum masters", create Jira tickets called "stories", and think they are "doing Agile", while using a process like that. But that's seems like cargo-cult agile software development to me. I do agree with the narrower critique that it's hard to present a broader roadmap with Jira; I've found Portfolio to be only OK for managing sequencing of Jira epics without getting bogged down in the details of individual stories.

partycoder 8y ago

If you define and implement all user stories, in the end what you will have is: a functional prototype, not a product. A finished product can be sold ethically, a prototype cannot.

facorreia 8y ago

> And so people take tickets, implement them as written, pass them off to whoever is next in the workflow Sounds like a process problem and communication breakdown, not a JIRA issue. We use JIRA and it isn't like that at all.

antod 8y ago

> Jira was designed for agile software development like Scrum,... Alternative view: when agile software development features finally turned up for Jira, they still took a while to graduate from paid plugin (Greenhopper) to core features. To me "designed for" always felt like "tacked on", and that they were somewhat fighting existing legacy object models.

FlyingAvatar 8y ago
This. JIRA has been around over 15 years and definitely supported other workflows before it supported Agile ones specifically. To me, it has felt in need of a complete rewrite for probably half of that time. If you've had to do administration for it, or have had to dive into more complex configurations, it definitely feels like it's more baggage than product.

JohnBooty 8y ago

Jira was designed for agile software development like Scrum, so you should write user stories, not mini specifications. Yeah, this is true. I was at a company that did Scrum. There were two managers who functioned as product owners on the scrum teams. Manager A took the correct approach. Developers were aware of the overall goal, and we broke those goals down into stories, and broke the stories down into tasks. As developers we had a good sense of ownership and responsibility. Manager B tended to just issue stories (which were really mini specs) to us. We were treated like children. We didn't know why we were doing what we were doing, and were not able to contribute to the design of the solutions we were handed, which were often suboptimal. A lot of teams take "Manager B's" approach and wonder why the developers hate Scrum.

rficcaglia 8y ago
I love being manager A. I always start sprints/epics as manager A. In my experience 1 of 5 projects succeeds with Manager A and I get a very superior result with a solution I myself would have never thought of. Rainbows and unicorns everywhere! But...the other 4 times I get either no solution, or the Upload button only works as long as one user at a time tries it, or only on Chrome when all customers use IE8, or the documents randomly disappear when new dockers spin up, or the button needed to be WCAG compliant and no one bothered checking, etc. Suddenly I am forced to be Manager B and no one is happy. The feature is 3x over budget and 3 weeks late. What leading indicators can we use to predict or at least alert to a failing Manager A project early in the cycle so I can do what I love, devs can do what they love, biz stakeholders get things on time and on budget, and customers can get something they love?
- JohnBooty 8y ago
  > 3 weeks late Whatever's going on, you gotta catch it sooner, right? Any way the stories can be smaller and get out to QA sooner? Maybe you could try being "Manager AB" Instead of a totally hands-off "Manager A" style maybe you can work more closely with them to develop those stories and make sure they understand what technical requirements (WCAG compliance, etc) each story needs to hit before they estimate them

dominotw 8y ago

> Jira was designed for agile software development like Scrum it says it was created in 2002

swish_bob 8y ago
Snowbird was 2001. That said, I remember using Jira before it had any understanding of an agile workflow, because part of my job was creating one in it.

rawoke083600 8y ago

lol scrum... what a wasted time those meetings were... pulling numbers out the air...

shliachtx 8y ago

> 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. I think that practically this often ends up being "As a user, I would like to have an upload button", Of course, adding "As a user" to the beginning of a sentence does not a user story make.

tynpeddler 8y ago

Don't write user stories. Many of the tasks that can be accomplished in a sprint aren't actually useful to users. In addition, stories aren't for users, they're for developers. The story, first and foremost, must be friendly enough to the developer that they can pick it up and work it. Instead, write user features. Let the developers write the stories. It took a while to convince my team of this (agile consultants can do a real number on people sometimes) but in the end, it let everyone write down and organize what they needed to, and it helped us organize all the work in a single hierarchy.