The good thing about Bugzilla was that it was clearly a bug tracking system (and it was excellent at that), whereas Jira is only a passable bug tracking system pretending to be a project management tool.
I've used Jira for quite a few years at work, and the number one issue with Jira that I have found (and also my team) is that bugs that don't get fixed tend to get lost in the mass of everything registered in Jira.
Jira does try to both be a place to register bugs (and features and other tasks) while also trying to be a place where you organise how the work should be done (eg. with sprints). I guess Bugzilla doesn't do that?
A good bug entry is (completely) unlike a project planning entry. It comes with detailed environment and repro instructions, artefacts such as logs and screenshots. It’s an investigation, not an item in a wish list, and it’s ideally a place where every dev in the team can chip in and offer additional data or suggestions.
If it isn’t used to track progress or productivity, it contains exactly the right number of entries (since there is no incentive to the contrary). The criteria for closing a ticket are very clear, there is no risk to offend someone by closing their half implemented and ultimately insufficiently detailed entry for example.
Bugs are either open or fixed!
The tool does not figure out who should be fixing which bug, that’s the job of the team lead.
When an issue falls on the fence between a feature request and a bug, whoever is allowed to make the call needs to decide and either keep it as a bug, or mark it as wontfix (either out of scope, or to be looked into as a feature).
A well maintained bug tracker is valuable to users, because it comes with a good search implementation (Jira’s search is abysmal for error messages!), and then can work if and when the problem they hit has been fixed.
Cluttering that with project management does not help!
But is it really that useful to track bugs separate from other work? I find that most often it's even hard to agree what IS a bug and what isn't. There is just "work".
A bug is a difference between the intended behaviour of the code and what it actually does! If you regularly can’t decide what tickets are, then you must be working on something that is especially under-defined and under-documented. I would suggest addressing that, and that Jira is not going to help you there.
I think the reality is that software is very rarely specified enough that you can go to a central specification and point at it and say "look here in the spec it says it should do X"
Something unforseen is occurring that the spec never talked about and that's reality. (trivial example: if you design without full unicode support you don't explicily SAY in a specification that you aren't supporting some characters, nor would you say you DON'T support such characters). And then a customer comes and says his name shows up as gibberish and you have no tests and no spec mentioning whether this is expected or not. It's simply a case that no one had thought of in neither specification nor implementation. The fact that it wasn't specified makes it easy to say "since we didn't expicitly mention it, it must be a bug".
It's in my experience usually futile to point fingers towards whether something is a bug or a new feature in this case. The customer obviously doesn't care, to him it's just a bug even if it's a lack of a feature (because the customer doesn't have the specification even if one exists). So to the end user it's very much a bug even if to the development team that may have written a spec that says "it shall be iso8859 and garble any utf-8" it is a completely new feature!
And even in the latter case where even the buggy behavior was well-specified, you'd be having a bug report describing the garbled text as a bug. The best you can hope for in a dual bug/feature system is to close the bug report as *wontfix - by design - see feature 123 in the feature tracker 'add unicode support'". This may be a trivial and perhaps obvious example, in most cases these realizations may take a large portion of the time.
Now: a public facing bug-report system feeding into a separate bugs-only-tracker can certainly be useful still, but once those end-user bug reports are converted into work, whether it turns into a workitem in a separate system marked "bug" or one that is marked "feature" isn't really that important. Work has to be prioritized in the same queue anyway. The ROI for fixing a bug, specified or not, has to be weighed against the ROI of adding a feature.
Sure, sometimes someone with the ability to do so needs to make a call and decide if the issue is to be treated as a bug or a feature request. It does not follow from it that planning and bug tracking are the same thing and are best done with the same tools.
Work tracking is also not the same as bug tracking (or planning!), and it is not obvious that all “work” meaningfully goes into the same queue. A dev lead with a basic grasp of context switching costs and specialised knowledge will instead look at several streams and organise accordingly.
It absolutely makes sense to keep planning separate, if for no other reason than the planning process and details rarely benefit from being exposed directly to the users.
Bug reporting and fixing on the other hand is at its best when it is fully open, and is a valuable resource for users.
Say one of our users clicks a button and expects our program to do X but it does Y. To the user this is a bug, regardless of the underlying reason, and it might be an urgent blocking one as such.
What's the value of tracking such "bugs" in one of two places, depending on the underlying reason? In either case I might have to get the button to to X in a couple of hours.
What made it a good bug tracker? I still use it and find may design choices like not being able to edit a bug or comment frustrating. Also the lack of some basic formatting in the bug descriptions.
This is absolutely correct. I've seen the analogy of the city build-out occur again and again as teams become fixated on tickets instead of understanding the overall problem and architecture.
Apple has a system called Radar that treats everything like a ticket. Projects are tracked completely from Radar.
Considering Apple manages to ship pretty decent software, I don't think blaming your tools is really appropriate.
The only real difference from Jira was that despite coming from the Carbon era of design, Radar was much nicer to use because, as a native application, it showed tickets in a regular table view where you could multi-select, drag and drop, etc. I personally find Jira miles more confusing than Radar after having used both extensively.
But that's a fairly minor difference, the design paradigm was the same.
There have been at least a couple of posts here that had thread discussion about this approach at Apple leading the focus to be on features over bugs. That things don't get fixed. Before holding Apple up as an example of good, best to look into those as those complaints/comments here mirror things I've seen on other venues in terms of features versus working software being shipped by Apple.
And yet, compared to, say, Microsoft, are their bugs any worse or more intrusive? Apple's software has at least been relatively stable for a long time. That is not a track record Microsoft has.
With Microsoft, I'd say it depends wildly on the team. I've known .NET to be rock solid stable. Similar for Visual Studio - most Visual Studio bugs I've experienced turned out to be ones that JetBrains was injecting through the plugin API. Office, too, is a pretty well-turned piece of software, especially considering its size and age.
It's largely the Windows team that has a hard time getting its act together.
.net frameworks like wpf are horribly buggy and horribly designed. Of course if you talk about the system libraries and vm then it’s pretty good but same with any language. That shit is engineered and not user-storied
That emphasis on features over bugs is a myth. Look at almost any Apple developer’s assigned Radars and they’re mostly bugs. Pay attention to Craig Federighi’s initiatives and stability, security and bug fixes have taken a top-priority at least over the past year or so. Look at iOS 12 and Mojave for public examples of this focus. People complained that iOS 12 didn’t have a lot of new features, but it’s almost universally acclaimed as far more stable and performant than iOS 11. Same for Mojave. Compare that to the release of Sierra for example.
That could just come down to Apple's cycle. They tend to do one release with a lot of features, then one release for stability. The precedent was set with Leopard and then Snow Leopard, repeated with Lion and Mountain Lion, and so on.
I expected to read this as a "Ah yes, another JIRA bashing article." I've tended to view JIRA as "the worst of all project tracking tools, except for all the other ones" so I like to rise to its defense when I see folks complaining about it without taking into consideration the needs of other stakeholders.
That said, I've found myself agreeing with pretty much everything in this article. While I believe that JIRA (if properly configured) can serve as a good issue tracking system, attempts to do top-down, high level planning on it have always left me with nothing but frustration. My advice would be to completely ignore any of these features (e.g. all the "portfolio" add-ons), do high-level planning down to the epic-level in something else like Excel, and then map that to tickets in JIRA. The "Nirvana" of having complete visibility from very high, enterprise executive level planning down to the "what am I as an individual developer working on today" level in one tool is a false idol and just not possible.
My manager had a rule, that each member of the team was only allowed to have one unresolved ticket at the end of day.
We had a weekly meeting where we would be badgered about every >1 unresolved ticket and had to come up with an action plan to make sure it never happened again.
So coincidentally, we would "forget" to create a ticket for every issue, that would take more than a day, until it was one day from completion.
Is the idea behind this "I can only focus on one thing at once, so unassigning myself allows someone else to take up the task in the intirim", or something else?
Mostly this. Obviously, this assumes shared understanding of assignments as "things I'm working on" rather than "queue of things and also commitment do to everything".
Combining the original "one open ticket" rule with the second approach is rather bad. That's why I hope it was used in the context of the first approach.
What gets measured gets done. If closing lots of tickets is seen as productive, you not only get lots of very granular tickets, but all sorts of grouping tickets and epics as well!
But all things considered, was the situation improved by that rule? I understand that it could be worked around ("cheated") but did it bring benefits as well?
If someone has a reason for this rule, feel free to chime in. I believe it was an implicit way to tell us to do overtime off the books.
Most of the issues, that took more than one day, couldn't realistically be completed in one day. Waiting on other parties, too many issues at once, low priority, etc.
Occasionally, a ticket about something non-urgent, with no follow up from the business users, would get dredged up from the past to finally get worked on again. But I would attribute that to generally cleaning up unresolved ticket, rather than a benefit of the rule.
The theory would be that you can't have any more than one "thing I have started doing, and will resume doing first thing in the morning" which should be the meaning conveyed by "in progress" and everything else should be yet-untouched "backlog" or in a priority queue "prioritized" and therefore out-of-mind, or explicitly marked "blocked" with a comment about who or what is blocking it -- so that there's no question about why things aren't getting done or who is working on what (if everything on the board is sitting as "in progress") so people aren't over loaded, haven't bitten off more than they can chew, or have a bunch of things blocked but haven't raised their hand and spoken up about any of them (the typical dysfunctions).
This is another excellent example of how making rules only tends to encourage working around them. Things get done when they get done, and no amount of managerial bureaucracy will make things go faster.
I'll try to explain the perspective some people have, including myself, about tools like Jira.
I do not believe that what Jira attempts to accomplish is possible. Organizations tend to utilize Jira to automate project management. I see that as a mistake. I want managers and project owners to be forced to keep the entire project in their head as much as is humanly possible. Software development is a messy process with a lot of moving parts and cliffs someone needs to be looking for to avoid going over.
With Jira I see people attempt to essentially automate keeping track of the project and they stop having a high level and deep understanding of the project. I think Jira helps make certain role's jobs easier, as opposed to making them perform better. In shops where Jira is heavily utilized, most developers and managers tend to get in their own little worlds at the expense of the project as a whole. Which again is because not having to worry about the entire project is more comfortable for everyone at the expense of the overall success of the project.
I find that smaller more specific tools solve enough of the problem of project organization and tracking without the side effect I described above.
I know this is a bit of a hot topic and I understand and appreciate that many people do not share my opinion.
I'd go so far as to say that, when I'm wearing my project manager hat, our tool (which isn't Jira, but is similar) actively wants to make things worse. When I'm wearing my product manager hat, it's simply a disaster.
Sticking everything in a ticketing system makes keeping a project organized more difficult for the same reason that owning lots of stuff makes keeping your house organized more difficult. There's only so many random odds and ends a person can be expected to keep neatly arranged. Especially if keeping them arranged is tangential to their actual job.
I got a lot more effective at my PM responsibilities, with a lot less time spent doing it, after I laid some ground rules limiting the use of ticketing system on my project. One of the main rules was, if nobody needs to be actively thinking about it right now, it doesn't get a ticket.
I have seen attempt to make project roadmap for next 6 months in JIRA, that was terrible. It is confusing for developers, it is confusing for business people, you cannot show it to the customer because they don't care about your tickets. It was too much of work to go through it so stuff that was not built because prio changed had to be closed and all clicking around taking too much time.
I think you should have next 2 sprints of work max in there, probably better if you only make stories for next sprint.
I think the odd thing about this thread is that ticketing systems really only provide me a value-add for stuff that isn't being worked on actively. Oh its time to pick up this ticket, its marked as high priority, here's a conversation about it in the ticket, here's the acceptance criteria, etc. If I know what I'm working on all the time I can just write it down in my notebook. Its the stuff where I needed to step away to another task for a week or something and I've lost my mental model for the last task, that's where JIRA can be a helpful tool IMO.
For the meta project/product management I'm just not sure. I'm endlessly frustrated by estimations and burndown charts that never seem to look good. The estimates are always too high, and the burndown charts often look like horizontal lines (sometimes they even go UP). And you can't figure out the cause of that shit by looking at a chart, or even at the board of tickets. You would need to talk to the team to figure that out.
It depends on your problems. Small companies have different problems in mind than big ones, so it might work pretty well for some smaller companies. In big companies, as GP said, it is often a utopian idea of full transparency and automatic progress generation in one click. Reality is more complex, of course.
JIRA is omnipresent, therefore critique should be taken with grain of salt – you can find complaints about too vague tickets/user stories and complaints about too detailed tickets (with implementation details).
The limitation isn't really our tools, to some large extent it's our brains and our ability to wrap our head around the whole pyramid. In a tiny startup that might be manageable, but even at 20-30 people you have to start abstracting.
When you choose to use JIRA for something, you are giving up an organizational dynamic where you previously depended on judgement, and you are now handling it with process. Judgement is adaptable but very hard to scale, process is rigid but maybe too easy to scale by fiat (whether it's a good process is a different question).
To be clear I don't mean that your PM's become mindless drones the moment you standardize on JIRA. I mean that where previously your 1-week projects and your 6-week projects would use custom planning processes, now with weekly sprints the 6-week project has to subdivide itself. There may be good reasons to subdivide longer projects, but I think this is an example of the class of problems that come from reality slipping through the cracks of processes.
When you look to JIRA or any other tool for the answer, you have to make sure you are not implicitly giving up the role that judgement plays as the safety release valve for procedural red tape. In that sense it's not even the tools' fault, because you can't blame them for trying. It's that the organization has to see the tool as "just a tool".
I think that in a large enterprise organization the scale of people who would have to interact with such a tool (from executives to developers) have reasonably different interests about what sort of information would be helpful for them and in what arrangement. As a thought experiment I can imagine one monolithic monster tool that could cater for all these needs. However, I think its complexity would render it utterly unusable. Much like there is no one person who can work comfortably at each and every level of the org.
Alternatively, this hypothetical tool may be a chain of components/screens/etc. mirroring the various levels in the org. However, I think they would likely provide unusable outputs, because without the precise understanding of how these components build on each other people using the tool wouldn't be able to populate inputs correctly and data may be wrongly classified/consolidated or lost (filtered out) very easily.
There is also infinite flexibility needed for such a tool because as middle management comes and goes they come up with various creative ideas about how to present progress and added value. This may lead to frequent changes in properties that can trickle down to the bottom without any well-defined meaning.
To sum up, I think it would just not be practical.
Depends on who else needs visibility. I definitely agree developers shouldn't be micromanaged, but IMO there is no such thing as an "80% done" ticket - it's either done or it's not. So things may need to be broken down a little more than a particular developer would want so that other team members (e.g. QA, design, management, etc.) can pick up their own tasks if they are dependent.
At the individual team level, yes, that is the point. However, at a higher level, my opinion is that JIRA sucks for this. For example, a company may have a high level initiative like "Move our infrastructure to the cloud." That initiative would then require projects from lots of different teams, and would require investment to make sure resource allocation is adequate. I've seen orgs try to handle all of this in JIRA, i.e. where the high-level reports given to senior execs who really just want to know "what percentage of our stuff has been migrated to the cloud" are generated from JIRA, and it always is a major pain in the ass that doesn't actually give a good view into what execs want to know in any case.
> I've tended to view JIRA as "the worst of all project tracking tools, except for all the other ones"
I've seen heard this opinion a number of times and I don't believe it's true. TargetProcess is a better project tracking tool. It has a deeper hierarchy for organizing work. It has the concept of teams built-in and allows you to view work across multiple teams and/or projects. It also provides a way to do roadmaps built-in. Everything is included and everything is designed to work well together.
As for the specific criticism about not being able to get a high-level and low-level view in one tool, I think the reason why JIRA does poorly at the high-level view is that it has a very shallow hierarchy of work entities. It has epics => user stories => sub tasks. While projects can also be used to organize work, JIRA unfortunately binds the concept of sprints which is more of a team thing to projects. Thus it's difficult for one team to work on multiple projects or multiple teams to work on a single project.
TargetProcess on the other hand has a separate entities for teams and sprints which allows projects to be used for organizing work. It also has an additional level in the work hierarchy providing the following levels: project => epic => feature => user story => task. This deep hierarchy allows you to group work into larger groups allowing you to see both the high-level and the low-level.
Portfolio allows for multiple layers on top of epics. Boards can be set up to pull from multiple projects, and boards are what are tied to sprints, projects are not tied to sprints (mostly, there’s some oddities).
Portfolio is implemented somewhat badly (Why the hell can’t I do skip level relationships?) but it certainly has the features you say you’re lacking.
Target Process is worse for agile. It is at once too flexible and too rigid. For someone who doesn't take the time to learn the tool, they end up with frustrating and not very useful defaults. For someone who does, you run into limitations like your backlog is always on the left or top because it won't let you move it around. It also ends up that as a power user you end up with a wildly different view from what everyone else sees, which causes additional problems.
Having a few extra levels of issue types in jira would be nice, but if you treat epics like TP features, you can use portfolio to add however many layers the PM and management team want on top.
Wow. I hate JIRA but this article gets it completely backwards. Having small-scale tickets that you actually finish is the very essence of agile - limiting work in progress, defining "what done looks like" in a customer-facing way for tasks that each last at most two weeks. Ignoring the "wider vision" is the best way to produce software that actually solves people's problems instead of beautiful n-tier architecture that doesn't do anything anyone wanted.
JIRA is heavy and slow - it's model of limited transitions is fundamentally flawed, encouraging micromanagement and making mistakes hard to undo. But a lightweight board that you push tickets through - the famous "kanban" - is a great way to develop software (I've had a lot of success with Trello, though I fear it's only a matter of time before Atlassian bloats it into JIRAness).
I agree with you about Trello, but even better than that is paper-cards on a wall.
Trello adds unlimited wall space and a distributed wall. If you don't have lots of remote workers, and the wall is big enough, then use it. There is something wonderfully tactile about chatting in front of a real kanban wall when working out priorities. At the next checkpoint/sprint meeting, you can physically add cards to your backlog. Physically push things up the priority list. I love it!
I like 5×3 index cards better than post-it notes..
The problem with trello is linking tickets intelligently is hard.
The concept of epic/subtasks is missing. So if a ticket becomes to big, and you want to keep the history while breaking it up, requires a boat load of copy/paste.
Also, there is a trend to have a physical board with tickets, as well as a trello board. This was fashionable amongst the scrum masters at previous large employer. It was universally hates as we had to spend loads of time playing with physical cards, then try and copy the state into the ticketing system. Its was annoying and a massive waste of time for everyone.
Especially as it didn't encourage people to write the work they've done on the ticket, to allow it to be taken up by someone new.
> Also, there is a trend to have a physical board with tickets, as well as a trello board.
Oh no! This sounds like a horrible idea! Two sources of truth, everybody trying to avoid the work of syncing them. Eek.
> The problem with trello is linking tickets intelligently is hard.
One way is to break any sizeable task onto it's own board. Just note on the card that it has been moved to a board of it's own. There is a logical team>board structure for this. Then you have a master board with the main building blocks on it, and then sub boards with tasks/stories on them. It is no panacea, but it can work
> One way is to break any sizeable task onto it's own board. Just note on the card that it has been moved to a board of it's own. There is a logical team>board structure for this. Then you have a master board with the main building blocks on it, and then sub boards with tasks/stories on them. It is no panacea, but it can work
We've experimented with this type of thing in my company. In practice, we found that having multiple boards for a single project is just a bit too much to keep track of.
I could see this working if Trello made it easy to quickly move between boards. This could be something as simple as a breadcrumb style path: Grandparent Board > Parent Board > Child Board, or something to that effect.
Or maybe that would overcomplicate Trello, I'm not sure.
Cool, I work remotely, can you point a webcam at your wall of cards please? Also remember to record your tactile chats in front of the wall so the rest of the remote team can hear them.
> Having small-scale tickets that you actually finish is the very essence of agile
Bollocks.
The "highest priority is to satisfy the customer through early and continuous delivery of valuable software."
Not tickets, small or otherwise. Not tasks. It has nothing to do with two-weeks.
> Ignoring the "wider vision" is the best way to produce software that actually solves people's problems
I have no idea what you could possibly mean by this.
Every time I've ever seen a modular development that isolates developers from the business (or from each other), I've seen brittle software, and that's assuming they get done at all.
> But a lightweight board that you push tickets through - the famous "kanban" - is a great way to develop software (I've had a lot of success with Trello, though I fear it's only a matter of time before Atlassian bloats it into JIRAness).
Listen, if software helps you, then great, but if your whole life is "pushing tickets", you're not doing Agile. It doesn't matter if you're using Jira or Jello.
Well, that's because there are so many false prophets.
I like Jira. It's terrible, of course, but way better than using nothing. Tech Crunch is mainly criticizing how "Agile" development is commonly used, to micromanage and give a false sense of grasp of the scope of a project for management. Micromanagement without the responsibilities coming with micromanagement (providing nice specifications, doing follow ups, taking responsibility for failures, etc) make me miss the waterfall model ...
Do not try to do True Agile, only try to realize the truth. There is no True Agile.
To me, Agile is really a set of principles to help you decide what to focus on (e.g people over processes). The different methodologies (scrum, kanban, etc) are just frameworks to help you build the best dev process for your team while trying to keep the agile principles front and center.
In reality, all kinds of factors get in the way of True Agile - experience of devs, team dynamics, company incentive structure, management expectations, management’s management expectations, how the company handles failure and the subsequent ownership vs finger pointing, etc. The actual implementation of Agile should be different for each organization because the environment in which they operate in is different. With that said, there are certain core principles and practices that are very beneficial across the board and consistency across teams within an organization certainly helps.
JIRA and Scrum are great ways to facilitate agile development but it's not bidirectional. I usually push rigid Scrum on teams if I think they lack discipline or experience. Follow the textbook until you understand why. When I'm working with smart veteran devs who know exactly why and how agile works, we can afford to be more freewheeling.
I think agile is fundamentally simple. The essence is the continual improvement. How that translates into a working process (like when do I write tests and who updated the docs) are going to vary project to project.
> Not tickets, small or otherwise. Not tasks. It has nothing to do with two-weeks.
Just what do you think "early and continuous delivery of valuable software" looks like in practice then?
> Every time I've ever seen a modular development that isolates developers from the business (or from each other), I've seen brittle software
Completely agreed. I've found any "vision of the project as a whole" is exactly where that isolation tends to happen: once this "skeleton of the city" is laid out, business input gets cut out because The Plan has already been agreed.
> Listen, if software helps you, then great, but if your whole life is "pushing tickets", you're not doing Agile. It doesn't matter if you're using Jira or Jello.
Nonsense. Again, how better to achieve "early and continuous delivery of valuable software"?
> how better to achieve "early and continuous delivery of valuable software"?
By building an application and putting it in the hands of the business as often as possible.
Thirty years ago I used a whiteboard.
I never needed ticketing software to build software or to ship software.
The only time I ever used ticketing software (from the contributor side of the fence) is when the business I was working for wanted it, and the only thing they ever did with it was track my time. Good for them.
Now when I'm on the management-side of the fence, I still don't really like ticketing software. I use Jira because the rest of their business uses Jira, and they want accurate reporting for R&D tax credits and doing KPI-based bonus remittal, and they've built reports and scripts on top of Jira. Some of my developers like to use the tickets themselves, and some prefer to let my assistant do the ticket busywork.
> By building an application and putting it in the hands of the business as often as possible.
Just putting the application in the hands of the business is not enough, you need to ensure that you're actually delivering value to the business. You need pieces of functionality that you know the business values (and where both sides understand what the valuable thing is) - i.e. tickets.
> Thirty years ago I used a whiteboard.
> I never needed ticketing software to build software or to ship software.
I'm sure I could keep it all in my head, but I'd rather spend that mental capacity on more important things. That you found a whiteboard useful says that tooling can be helpful - and Trello can be more convenient than a physical whiteboard.
> Just putting the application in the hands of the business is not enough
Yes, it really is. There is so much software that has been built without a ticket system. If you need examples, just ask!
Tickets can be a proxy for business value, in a way that a checkbook is a proxy for money, but it’s not the checkbook that pays salaries: Software is built in the brain.
> Doesn't the checkbook of a business literally pay salaries?
Hint: Some businesses don't even use checkbooks.
> I'm unclear as to what you're arguing here.
Is it really unclear?
Having small-scale tickets that you actually finish is the very essence of agile
This I disagree with. "lmm" seems to think that tickets are either "the very essence of agile" or perhaps even essential to "deliver value to the business."
I can believe you've built valuable software without a "ticket system", but not without tickets, whether you called them that or not. You need pieces of functionality that get agreed between the business and the developer. And while it's possible to keep them in both your heads, it's easier and more reliable to record them in writing.
> business input gets cut out because The Plan has already been agreed
But is this because the developers want that, or because management has carved in stone The Schedule, based on The Plan, and the only way for dev to stay on that schedule is to reject updates?
I love how much this comment is a perfect example of developers thinking about nothing but software development. As a sysadmin, I've custom written ticketing software, and used just about all of them, and the thing is Jira really fullfils a role in companies that most of the other ones don't, and I'm not even talking about software development! It's far from perfect, that's for sure, which is why I use jira from emacs. So many people here seem to think every business is a SV software startup and not just some regular old business trying to get shit done and it has repeatedly been a problem I've seen and I'm sure it's the cause many a miscommunication.
While I've seen non-software teams use Jira before as well, I don't think it's unreasonable to talk about Jira as a tool designed for software development; from their homepage:
"The #1 software development tool used by agile teams"
and
"The best software teams ship early and often."
and
"Development workflow: Jira Software automatically updates issues and transitions work when code is committed in Bitbucket."
and
"Continuous integration: Power your CI with Bamboo and monitor build statuses without ever leaving Jira Software."
Well yes. I do develop software, but I've always thought of myself as a sysadmin who programs (AS21863 for over a decade) instead of a developer who "ops". These days I'm also an executive (of an LSE listed company). I do these jobs differently, even if I use (some of) the same tools for each.
I think a lot of people believe that it's their tools that make them able and forget it's their brains that use and make the tools.
I also think that anyone who thinks using a particular tool is essential (as opposed to meritorious) needs to get their head examined.
Do you have any details about your emacs/jira workflow?
There's a middle ground between shipping a bunch of features and beautiful architecture that does nothing. At the end of the day, spending heavy up front time on designing great, flexible architecture lets you iterate much more quickly to ship the features people want.
> At the end of the day, spending heavy up front time on designing great, flexible architecture lets you iterate much more quickly to ship the features people want.
Not my experience. The most important way to get flexible architecture is simplicity - not having things you don't need. More often than not, architecture designed for some kind of flexibility up front turns out to impede flexibility in a different direction (which was actually what was needed) where a more naive design would have been fine.
What do you like and/or hate about it? My company is considering migrating away from Trello and I'd like to arm myself with as much information as possible on this topic.
What I see in this article is a point that there's a discrepancy between goals and tasks needed to achieve these goals. If you're using JIRA for both planning features and measuring work hours spent (which many organizations are) then this brings some trouble - in an agile sprint, it makes all sense to plan that you'll do features A, B and C this week and get to D and E next week; however, it may be that by the end of the week you've spent 4 hours each to finish A, B and C and 20 hours on an infrastructure task (that's mostly done but not yet) that's needed not only for A and C but also for the next week's tasks.
The detail level and task breakdown which is appropriate for planning which features you'll prioritize and do for a sprint may not be a good task breakdown for actually assigning sub-tasks for people, looking at their progress/status during a sprint, and mapping particular commits or hours worked to them. JIRA common practices sort of force those things to be the same, which may be considered harmful.
I sort of agree with you but I love JIRA. Tbe problem really lies in the way people use it. It’s just another tool, and it can be used any way your organization deems necessary. Unfortunately, most orgs tend to make a religion out of it, and the Agile process becomes bastardized by abusing JIRA. Just by observation, I have concluded that management loves JIRA precisely because it allows them to micromanage (“hey Temporallobe, how are you coming with story XY-5678? I see it’s been in-progress for 3 days...”). Again, that’s not JIRA’s fault, but to use an Agile term, it’s an “enabler”.
Tools drive the way they get used, and JIRA naturally guides teams into micromanagement. Have you tried a more lightweight cards-on-board tool (like Trello)?
I'm not going to defend Jira, but don't you just need to break down each ticket into smaller ones.
To use their metaphor. The airport gets a ticket. Then you put another ticket up that says 'find a good field to land in', then another that says 'level out field for x class of plane', then another that says 'install basic lights'etc.
Things are now getting marked complete and you are agile all over again.
Presuming you are letting Jira decide there is a logical link, I suppose. You don't have to, do you? I must admit I haven't used it an awful lot, but maybe this is one of those traps that you use the functionality because it is there, even if it is not useful.
In this example you could for instance create 'Airport' as an task and just write on it that you are going to aim for a dirt strip first and are going to start a separate task for this.
This is the power and weakness of Trello, there is no link! Except of course you can create a new board called 'dirt-strip'
What if that turns out to be an inefficient (poorly-architected) way to break it down? But it's half-implemented by the time someone calls attention to it, and it doesn't get re-architected because it's too late now.
Breaking things down appropriately is, in my mind, 80% of the work. If you have your head straight, the implementation is easy; but it can take implementing virtually the entire thing to get your head straight.
Well, the developer didn't need it in the first place. It is not a useful tool for developers as we have better tools for developers. It is management that wants to see the work up in pretty JIRA lights and they want to see it before the project is already done.
That's how agile should be done. You should plan out the things that you are doing short-term in more detail and the things you are doing long-term in less detail because you don't know as much about it and it is more likely to change.
The problem is many times you end up with tickets like 'create a runway' when there are already four perfectly good runways but the person doing the breakdown didn't realize that.
And if your developers don't have a bigger picture understanding then they also won't know that there are already runways they should be using.
Jira has always been very quick and responsive for me. It offers a good amount of customization too, we have a custom workflow that makes sense for how we develop software. I've never felt that jira has been a limiting factor of what the teams I've been on have wanted to do with our workflow. Never once encountered a major bug in it either.
It’s infuriatingly slow for me. Is this a configuration thing? Are our teams doing something different?
It seems to me that it’s slow on a number of levels. It just takes a long time to load each page, and on top of that, basic operations usually take far too many clicks. So I figured it was just a bad tool.
Jira Cloud & Jira Server (on-premise) are two different beasts. I can speak for on-premise only. On my on-premise system which is located on the other coast of the country, a ticket loads in 1.5 ~ 2.5 seconds once your assets are cached at least once by your browser.
Things I've seen that can adversely affect your speed: installing random plugins that are poorly written, integrations, having too many admins over-complicating the Jira configuration.
Learn the keyboard shortcuts to speed up your basic operations.
> It's like they spent much more time refining the UX and feel of moving around clicking on things.
I just gave it a whirl - for an hour or so - so take this with a grain of salt.
Looks much nicer, and there definately has been more effort put into the design compared to trello / jira.
Thats about where things end for me though.
I don't think the UX is refined at all, it's full of usability faux pas and their CSS could undergo some basic usability testing as well.
Jira's usability isn't that bad if you use sane defaults and avoid overconfiguration. Jiras main problem (and its a big fucking problem) is responsiveness.
I did have a look at their suggestion forum and it looks very active I think I'll give them another look in a few months to see if they've managed to reign in some of the BS or if it only gets worse. (I suspect the latter will occur for various reasons.)
And please, don't take this harsh critique the wrong way, if I was choosing a platform today I'd probably pick them, beauty is a hell of a drug - just don't confuse a nice looking design with UX.
>But you need something else for the macro. [...] Allow me to propose something shocking and revolutionary: prose.
[...]
But it is a tool deeply ill-suited to be the map of a project’s overall vision or infrastructure, and it is never the source of truth — the source of truth is always the running code.
I'm not sure what Jon Evans means by "prose" to document the "macro vision"... a freeform text file? MS Word doc?
Personally, I need more structure than that so I use a spreadsheet for it. I like to create columns of metadata to assign a priority, notes about difficulty, estimated time, estimated cost, etc. Any large project will have hundreds of wishlist features that need to be organized. Prose is too unstructured for that. Maybe JIRA is too bureaucratic and the wrong tool too; I'm not familiar with its goal-planning tools.
I can't store the "macro vision" directly in source code because many wishlist goals are greater in scope than placing a commented out line in a cpp file such as "//TODO:implement voice recognition."
Yes, the source code is a "source of truth" but it's only truthful at the abstraction level of generating an executable. It's the wrong abstraction for gathering wishlists, future goals, and priorities.
> I'm not sure what Jon Evans means by "prose" to document the "macro vision"... a freeform text file? MS Word doc?
Yes. Sometimes.
> Personally, I need more structure than that so I use a spreadsheet for it. I like to create columns of metadata to assign a priority, notes about difficulty, estimated time, estimated cost, etc.
I think having a spreadsheet is good too.
This isn't either/or.
> Yes, the source code is a "source of truth" but it's only truthful at the abstraction level of generating an executable. It's the wrong abstraction for gathering wishlists and future goals and priorities.
I don't think that's what is meant by this statement: the source of truth is always the running code. I read it a call for an iterative and evolving "design" that comes from the program as it is run, instead of some repository of code or tickets.
To engage with JE's particular essay, I think it is either /or. He emphasized "prose" with italics. Seems a reasonable interpretation is that he thinks the rigid or incorrect structure in Jira is wrong to document a macro vision. If he thinks another structured tool like MS Excel or MS Project is a desirable alternative, it seems he would have mentioned it. Instead, he recommends prose.
To be pedantic, one can type "prose" right into Jira. But that would be an uncharitable reading of his essay. Therefore, he must mean something else: a document that's more freeform.
>I read it a call for an iterative and evolving "design" that comes from the program as it is run
If he meant that, he's wrong because the running program is always an incomplete picture of what you desire the program to do. The "desires, goals, and design" -- ultimately has to be stored outside of the source code and therefore, it can't be a source of truth for that type of macro vision.
(Yes, there is a school of thought that proposes that "the source code _is_ the design" but I've always seen that as more of a reaction to UML diagrams and flowcharts from CASE tools that get out of sync with the actual code. To really fulfill the "code is design", it would require an extremely powerful declarative language compiler that turns high-level English specifications into executable code. Using today's primitive languages such as cpp and h files isn't a good way to express "code is design".)
Yes, the macro-level view belongs in prose. In a word-doc perhaps.
All I meant was that this doesn't preclude the use of tools like Excel (or Jira) to break up tasks into items and estimate their cost. If you like doing that, then great: you're not doing anything wrong.
We are looking at planning tools (digital agency, many clients with needs that rise and fall, small team of developers). We would love to have a time based resource planning view.
Weren't really considering jira, but would love to hear any suggestions.
This article makes some really good points about the importance of knowing the larger project and infrastructure context when digging into details of a software project to fix bugs or add features.
And, I'm not a fan of Jira.
But, the difficulties noted in the article feel wrongly assigned to Jira. They aren't Jira's fault. It's a process problem of the org using Jira. A deficiency in the way projects are architected, documented, and communicated about. It's not the tool itself that is the problem.
> 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.
>"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."
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.
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.
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.
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.
It's a common pattern. When a software system becomes complicated and fragile, it's quite common for the developers to get scared of breakage and move slowly.
Sometimes there are fundamental reasons for moving cautiously, and sometimes they're accidental reasons that could be fixed with a better process (such as better tests). Either way, just being more reckless isn't going to help.
Dumb question: If you implement $xy but know $ab and $cd are likely to follow, would it be against scrum to directly implement a generic upload button?
I haven't done scrum but I don't think it says anything about this. Back when I was doing XP (a long time ago), the idea was that it should be shippable in case plans change and you never get to $ab and $cd for some reason.
So if you had in mind a generic upload UI where it would look weird with only one choice in the menu, then better to skip the menu entirely for now. It makes the UI worse, and implementing the menu is more work. Plus you don't want to end up with dead code lying around if plans change, since that could confuse someone later.
But if none of those considerations apply and the generic version is actually easier to implement and the UI is just as good, sure it's fine.
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.
> 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.
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/
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.
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.
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.
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'.
Because "Oh, come on!". Just because you can implement any process in a list of text files and grep it does not mean you should. Jira has features that Bugzilla does not or needs plugins for. Should you just throw all of that away?
"Capture the larger user story". Why should I disintegrate information among many Jira task names and descriptions instead of writing readable and organized high-quality documents?
I'm used to use Jira only for timesheet purposes: hierarchical decomposition (project X, activity Y, often also employee Z) allows stress-free accurate accounting.
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..
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.
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.
there's also a blended style where you start with FDD then perform SDD in the refactoring. This way you're not performing blind architecture - you make the necessary change and you systematise the solution during refactoring, if it is a change in system behaviour. You can use this technique on an ongoing basis at a per-ticket scale and trust that you are 1. not violating YAGNI and 2. always in a state of minimum-viable-well-designed-architecture.
Or it leads to dicking around forever while you change your mind five times about what the "proper structure" is because you're not comitting to anything and not getting any feedback. Experience has very little influence on that.
If someone is playing around trying to get a proper structure it really is a lack of experience.
If a person repeated the same project 5 times on the last attempt would require very little trying to find the proper structure. Experience has everything to do with that.
"Analysis paralysis" is a real thing, so I partly agree with you. Sometimes you have to take parts of a large concept and "dick around" with it to discover the unknown unknowns and how not to do it, then feed that back into analysis.
After a number of iterations of this, you converge on a baseline architecture that you try to support future change without being excessively focused on YAGNI. Over-focus on YAGNI often leads to architectures that are so inflexible that when you DO need it, you can't add it without a demolition crew[1].
People should also remember the context in which YAGNI came up: Kent Beck, Ward Cunningham, Smalltalk, and the C3 project. This particular combination of people, project, and process made YAGNI feasible. And the C3 project, which spawned XP, was not as successful as folklore would have it[2].
It's not always so. Imagine if YAGNI was the focus of Roy Fielding and the HTTP specification, which has lasted remarkably well because of allowance for future change in the architecture.
Scrum and other processes that claim adherence to the Agile Manifesto work best in certain contexts, where code turnaround can be fast, mistakes do not take the company down and fixes can be redeployed quickly and easily, the requirements are not well-understood and change rapidly, and the architecture is not overly complex.
Many other projects don't fit this model, and people seem to think that so-called "Agile" (which even the creators of the Manifesto complain is not a noun), and mostly Scrum, is the sole exemplar of productivity.
The fact is that there are many hybrid development processes, described by Steve McConnell[3] long before the word "agile" became a synonym for "success", that may be more suitable to projects that have different dynamics.
An example of such a project could be one that does have well-defined requirements (e.g. implementing something based on an international standard) and will suffer from a pure "User Story" approach.
Let's be much more flexible about how we decide to develop, and accept that you need to tailor the approach to the nature of the project, based on risk factors, longevity, and other factors, and not on dogma.
And let's not underplay the extreme importance of a well-thought out architecture in all but the most trivial of projects.
There's many ways to split a story and oftentimes I would argue that creating a smaller version first makes the code better. Ie writing code that you _know_ will have to change not far off in the future.
If your problem's complexity is big enough, you can't get good solutions without an explicit architecture step. I've seen quite a few bad ad-hoc architectures being created trying to break down epics that were too big. Your team needs a lot of discipline to come up with a good plan/architecture (per story/epic at least) first. Scrum did not help here, to me it seems it legalized hacking away the day... In some domains you can't pay back that kind of dept easily...
The article may have a clickbait headline, but „have an overview and use JIRA in addition to track the leafs of the work hierarchy“ is true.
What I found is that almost all projects try to organize as tree but they should organize as matrix, at least if there are many cross-cutting components.
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.
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.
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.
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.
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...
> 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.
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.
What if importing an excel sheet actually means importing an excel sheet, formulas and all, instead of a CSV? Commenting on a hypothetical estimate on a hypothetical story isn't adding much value...
Ironically, this is a pretty good example of why tickets end up the way they do in jira - overly specific and concrete. Even the hypothetical situation is getting misinterpreted.
I would still love it if user stories were implemented as the "why" (or even "what") instead of "how", though.
Stories should absolutely be a "what" and a "why." Stories are property of the product owner and they are ideally writing them. The "how" is up to the team or implementor. If your product owner is specifying "how," that just sounds wrong. Maybe they could suggest how if they are a domain expert.
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.
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?
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.
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?
The solution to this problem is to solicit user feedback all the time. As in, the moment you get your code kinda sorta working you get some feedback from the ultimate end users (e.g. NOT the product manager, LOL)...
"This rough implementation is how I (we) envision this feature working. What do you think?"
"We've got the feature working well but it requires non-trivial back end changes. Would you be willing to wait or will you be satisfied if it works but only in a very manual way until we get the back end changes in place?"
Week 2 after release: "The feature is live... What do you think? How is it working?"
These are conversations the developers should be having with the end users. Regularly! It's when developers only ever talk to their boss and/or the project manager that pushes development into the anti-user zone.
That is also feedback. Having unresponsive customers is a bad sign, often suggesting that maybe they're not as interested in the product as the smiles the hyper-gregarious sales team receives would suggest.
The software for it has to work. There will be months of work implementing the rules engine before you have anything to show the customer besides a mock-up..
You won’t really need two week sprints to get feedback from customers. It either implements all of the rules or it doesn’t. I can imagine the same happening for tax software.
That’s taking a strictly algorithmic approach, and assumes the rules are equally understood by all parties and have no inconsistencies or undefined states. And as an example, I happen to know TaxCycle is unusually responsive to customer feedback on releases and offers early previews. Here’s a list of improvements from 2017 feedback: https://www.taxcycle.com/News/Your-feedback-becomes-features...
Your customer might not have the manpower to test your product all the time. They're presumably already spending a lot of money on you, they might not want to spend an extra headcount just for testing your work. They might feel that that's your job.
Happens all the time, and usually ends up in disaster. Not willing to test means that don't know or care, and you are throwing darts blindfolded hoping to luck into what they imagine they want. I've been on projects customer would say, "I don't need to see it, I know you're going to blow us away!" You do your best but it never ended well.
The best is when the team delivers 100% what was specified on the Jira items, do the demo after several failed attempts to get feedback and then they state that "it is nice but not really what we want".
If a customer isn't committed to the project, then I'd worry about committing to it as well. Even if the contract guaranteed I'll get paid, there are few things as demoralising as a project falling over because, once push came to shove, the customer didn't even have the manpower to deploy your product. Those are usually the same people who would do the evaluation, so with my experience, as an employee, if they're not there, I'm going to look for a project where they are — regardless of how confident sales might be.
The problem with all the devs talking to users is that many of them are bad at it and have no desire to do it or improve at it. So that means you are either very, very limited in who you hire or you have to have some devs that don’t talk to the users.
You must have much better end users than I have. My users seem completely incapable of looking at a half finished, sort of working proof of concept and not get bogged down focusing on everything that obviously doesn't work. I definitely agree that you should talk to your end users all the time, and ideally observe them working and using your product (or your competitors product) to the extent it's possible, but I've never had much luck discussing rickety proof of concepts with them.
> a customer went without being able to use that feature.
Well, by definition, a feature that takes 2 months to build takes 2 months to build. Shipping part of the feature early doesn't provide feedback for the finished product. It provides feedback for the incomplete feature. How valuable is that feature?
In addition to that,a feature that takes 2 months to build will take longer if you are releasing multiple sub versions. You have to account for actually making it production ready, and releasing it, and handling errors and feedback.
This is why experience matter. Was your feeling of control and happiness worth shipping half-finished, substandard product to your customers?
And in the real world, you often go through all of the ceremony of a “release” but it isn’t put in production until it’s complete anyway. Until then, the feature is just on a UAT server and the code is officially “in production” but it’s behind a feature flag.
The communication and coordination overhead of four or five developers working together is non-neglible on top of that if any part had to be reworked that also would have involved overhead between multiple developers. No matter how well you spec something out, there are always the unknowns - i.e. I forgot about this piece of business logic based on a checkbox on the front end which is going to cause a boolean to be passed in the model that’s going to affect all four services and a database table. Now I need to either communicate with all of the developers, or do it myself and dig through code I am not familiar with. In this case, I just make all six changes myself, do a quick test and commit the code and update the docs.
Then all four developers would have had to coordinate with the Devops guy.
This is all getting into “Mythical Man Month” territory.
Instead of me trying to explain it, I might as well crib the explanation from Wikipedia.
Complex programming projects cannot be perfectly partitioned into discrete tasks that can be worked on without communication between the workers and without establishing a set of complex interrelationships between tasks and the workers performing them.
Four equally qualified people should be able to deliver more features in the same amount of time working independently than four people working together.
Not if that early feature is broken and doesn't work. Then the conventional wisdom will quickly become "Don't use feature X, it's broken" and you're going to have to spend a lot of time re-educating your user once you've actually gotten around to fixing it (assuming you actually get around to fixing it and aren't pulled away to do something more 'important')
On the flip side, this has a cost of creating siloing/low bus factor, so if you were to ever get in an accident that took you out, or you left the company, the company would be potentially completely screwed.
I’ve learned the hard way from years of experience that if I am the only person that knows a system, that means I will be stuck on it forever and can’t move on to the new shiny.
When I was a team lead, I made it part of the “definition of done” that you had to have documentation and knowledge sharing. Now, I still have both an overview of my proposed architecture before I start just to make sure I didn’t miss anything, Visio diagrams,Powerpoint slides, wiki documentation, an “architecture review”, etc. I hold myself to the same standards I held anyone on the team to.
From a career development standpoint, software developers are a dime a dozen. It’s the people who know how to communicate effectively are the ones that get ahead.
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.)
Bleed-over is not normal in Scrum. If the entire team finishes early, complete the sprint and create a new one, don’t drag in more work unless the entire team can agree it will finish within the original timebox. Each sprint has a definition of done, and if you’re not going to deliver it, you’ve got to end the sprint and start a new one, you can’t change things mid-sprint and expect everything to run just fine. The biggest problem I see in practice, and Jira encourages this, are tasks assigned to specific individuals such that the team doesn’t feel empowered to take on sprint tasks “assigned” to other people. In reality, the entire team is assigned the entire scrum, and you can’t ever take pride in finishing “your tasks” early unless your team’s tasks have finished early too! I get it, though, there’s a difference between idealized scrum and what most companies implement using Jira. That’s definitely still a problem to look into, but I can only put half the blame at best on the tool itself. If the tool didn’t have flexibility to fit to any process, folks would just pick another tool that does. Jira is simply the least such a tool could do, it’s up to you to figure out the better process for your team... and Scrum is the least-worst process I’ve encountered so far.
True, bleed-over is not "normal", but I'd bet it's common. It's a sign that you're not doing scrum "properly". My own elevator pitch for kanban to other teams still in the scrum world is: if you're not having problems, then don't switch, but if you're having problems (some of which include bleed-over, some of which include long meetings) give kanban a shot. Some teams have switched back after trying kanban, too, it's not for every team anymore than any other process or tool is.
You could also say to switch up what scrum means if you're having trouble -- to be honest I've never considered the idea of just ending the sprint early (and rescheduling the sprint planning meeting!), I'm skeptical than any of the "Certified Scrum Masters" I know have either... But it still can't be done if you are finished early but the rest of the team isn't. My team didn't really have a problem with taking on work assigned to someone else so long as that work wasn't started yet, but things get tricky when all the work assigned has been started by someone. A solution in that case does present itself besides just bringing in something new, it's the same solution as kanban when the buckets are full: join another developer on their story and pair (doesn't have to be "formal" pairing even) to get it done faster.
But you've highlighted another problem with the whole mess, that being ownership accountability. Lack of visibility outside of the standup meeting into what Dev B is working on when they're paring with Dev A (who is the sole "assigned dev" in the tracking system) is an obstacle to incentivizing pairing. Sometimes you need that visibility. On an old team I left because of terrible management, there were just two of us devs at one point. One sprint it turned out that my face was on the dev column for almost all the items, the sprint before it was my coworker's face, in reality we paired on almost everything. But that second week my manager (who never joined our standups) asked "What are your thoughts about Dev A's work performance? You seem to be doing everything right now." Management memory was sprint-to-sprint. This isn't a problem with scrum, of course, though it does enable that problem to surface where at least in a kanban style you'd have the giant column of closed things having a mix of faces.
What I have seen mostly, is that the devs finish early (about 1/2 or 3/4 into the sprint), and wait for QA. And so, QA is idle at the start of the sprint. Bleed-over was then just accepted and incorporated, while I was not sure of the usefulness of "sprints" anymore.
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.
@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.
> 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:
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.
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.
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.
> 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.
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.
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.
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?
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.
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-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.
And final thought, "correct" or not, a guiding principle that's proven useful over time: individual tickets should deliver true pieces of "value" which is to say, once deployed, the software does more of what people need than before. So when a ticket is "done," it means something was improved however it was needed across all levels of the stack.
None of this "button here" "wire it up later" "now add the db table" etc.
I think it is possible only in simple software (when you are developing an MVP, or just early stages).
Complex tasks are incredibly hard to finish as a single ticket – with such granularity you might have opaque progress for couple days, and you hide a lot of details from everyone.
Unless you mean "tickets" as "user stories", they can be (although not always) treated like that.
Yeah - entirely depends on your subdivision vernacular. Some people make subtasks in a ticket, some people make tickets linked to other tickets, some people do both and link those to "features" which are themselves tickets (like the environment I work in).
>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.
It is very hard. At my last gig, we got to a generally good state where the PMs were responsible for periodically outlining their overall "vision" to the team, which captured what we're building and why we're building it. In stories, PMs were made to be very focused on focusing on "what", not "how", and to provide the context for "why". That let the PMs stay out of technical details and let the Engineers use their brains to fill in gaps.
It took some pain and effort to get to that point, but once we got there, it worked very well.
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.
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.
> 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.
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.
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.
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?
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
> 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.
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.
The author uses a flawed analogy to push a flawed argument.
Jira is a tool to track what stuff needs to be done. Using the author's city analogy, they appear to be advocating that all city workers need to have a vision of the whole city plan for any task they they are doing, that doesn't scale.
Large projects are to big to fit all the detail in one person's head. Design goals are broken up, issued to specialist teams, which then break them up again.
To then blame the tool for worker not bothering to understand what they are working on is not the fault of the tool, its the fault of the worker.
Ok smart arse, how do _you_ use Jira then?
Simple, its a big arsed multidimensional to-do list. There are a set of business goals with solid business deliverables(which of course translates into vague tech targets) Each team is assigned high level tasks. Its up to them to split them up and write down _what_ they want to do, and then in small subtasks _how_ they are doing it.
if they are too stupid to ask "how does this align the business need?" then they shouldn't be allowed grown-up scissors. (why are you hiring them?)
> Using the author's city analogy, they appear to be advocating that all city workers need to have a vision of the whole city plan for any task they they are doing, that doesn't scale.
For most projects, it does scale. The problem with almost all software development analogies is that they attempt to draw parallels between design and manufacturing. Software development is much more design than manufacturing.
A more suitable analogy would be art. Imagine a group of artists commissioned to create a painting. The designers decide, upfront, the main elements of the painting, then someone else breaks the work down into tickets based on those elements.
Unless extremely well managed, the result is likely to be hideous and the project is likely to have a high turnover of artists. This is pretty much what happens in most software projects. The real problem, as this article identified, is that a bigger picture perspective is needed. Unless a project is crystal clear about the big picture, everyone will have their own big picture and build features accordingly.
> The problem with almost all software development analogies is that they attempt to draw parallels between design and manufacturing. Software development is much more design than manufacturing.
Also construction.
The way I see it, what programmers do is not constructing a building, they're doing the architecture (and wiring plans, and landscape plans). Construction is what compilers do.
I've worked with artists, and that's precisely how it works. https://www.foundry.com/products/flix/new-releases is basically a visual pinboard. It allows storyboard artists to collaborate, give crit, and iterate on an entire movie.
Later on in the pipeline, the modelers, animators, lighters, texturers all have to take the storyboard input, combine it with the vocal cues and make an artistic thing.
There is an agreed upon style guide, with a very close feedback loop (dailies, weeklies and monthlies). all managed by something like https://www.shotgunsoftware.com/ or ftrack. which is basically Jira + MS project love child.
Its the same with software, There is a style guide (well should be, you can use this tech, with these standards, deployed and monitored by these tools) which lives outside of Jira. Jira is then both tracking tool (so the buisness can see progress) planning tool, so that decisions can be traced, tracked and adjusted, and notebook.
I can understand the hate for Jira. I was at a company where we changed workflow every sprint. Its dispiriting, annoying and wasted on average .75 of a day a week. Thats not the fault of Jira, that the fault of the people who take the religion of AGILE and impose it.
Process should be mapped to the system, not the system mapped to the process.
JIRA is meant to break up work. Atlassian has another product called confluence to let you write prose, like the author wants, and you can link all these things together. When you have a group of 3 people on your team, you need to coordinate different parts of the feature into separate tasks for each developer so that they can work in parallel. This guy/girl hasn't discovered anything we don't already know.
VSTS and Jira are two implementations of the same thing really. They are the two large enterprisey issue management suites.
They are "the worst except for all the others".
If you really are a huge enterprisey team that has many levels of visibility for various management levels and stakeholders, as well as large distributed teams working with different schedules and modules, then github tags or post-it notes eventually won't cut it. They are nice and streamlined for a while, but then someone will ask for a weekly report of X or a website showing progress Y and a corollary to my main argument is that someone is always to oblige with the request even though the correct answer may be "no! Let us just use streamlined tools and just make smaller independent teams!".
And in the end if you start off with post-its, the github issue tracker or some lightweight issue management system you'll end up according to this theorem:
Every software project management system in a large enterprise environment that isn't already a large enterprise one (like Jira), will eventually become an ad-hoc, informally-specified implementation of Jira.
It is, however, not a new antipattern. This kind of thing has been around since the 80s or at the very least since the POSIX standardization of SCCS.
Even SCCS supported something called "modification request" numbers. These could optionally be checked by an external executable, tracing each commit back to a ticket number.
I use vistimo.com for tracking what I build for clients; I built it specifically to alleviate the harm of the linear backlog, and help everyone share the same broad vision of where we're going, how long it will take, and what's changed about the plan.
Storymapping isn't a perfect tool for sharing product vision, and by trying to be storymapping+estimation+progress tracking, Vistimo is of course imperfect at each of those things individually; but having the combination has done me and my clients a lot of good.
That article is really awfull in expressing the root cause of the authors unhappiness with agile and enterprise scrum.
Jira is just a tool. To stick with bad anaologies: how can a screwdriver be an antipattern?
You can create a design ticket where you describe the larger overall picture (city planning) and then as you implement it, add enhancements (neighbourhoods and sewers) as subtasks. If something breaks when you add the enhancement, for example a memory leak when calling method X, you can create a bug ticket that only concerns the micro details.
In my experience, the problem is always in people, not tools.
Nowadays, Agile/Scrum is a buzz word, every company is trying to get it, but rare people understand it. They buy tools (like JIRA), they do standups, they assign story points...and then things become messy and it all turns into into a glorified waterfally kanban with story points.
JIRA is just a tool (bloated, maybe), nothing wrong with it. Personally, I find it to be OK -- no major complaints about it.
I used to feel this way, but found it to be an unproductive model until I realized something: sure, most people are kinda stupid and sufficiently intelligent people can make many tools work for them. But most people's actions are driven _very_ heavily by their tools, and from a pragmatic perspective, criticizing tooling that drives bad actions for the average engineer makes a lot of sense.
As an example: I recently ran a small engineering org (started out with just me, grew to about ten eng) working on a Python system. The founders had a lot of trouble sourcing, so we ended up with engineers that ranged from okay to mediocre to terrible. There's a ton of dangerous Python footguns that competent engineers have the discipline to avoid; engineering in Python at Google isn't exactly fun, but it's workable. OTOH, trying to run an engineering system in Python with the kind of engineers at this last company is a constant nightmare of catching and stopping idiotic abuses of Python's flexibility. Using something like Java would have imposed discipline on this engineers for a subset of the mistakes they were making. While it's true that sufficiently skilled engineers would've been aware of Python's pitfalls and worked around them, it's entirely fair to say that this permissiveness is a downside of engineering systems in Python.
As another example, I feel exactly the same way about Facebook: for all the talk about how usage makes you depressed and scrolling through the newsfeed is bad for your mental health, I'm able to use it as a messaging, photo sharing, and event planning platform and can't remember the last time I looked at the news feed. That doesn't mean that it's unfair to criticize Facebook for the effect it has on those who can't resist doing so.
To put it more concisely: while it's true that smart/competent people can think critically about the weaknesses of their tools and work around them, the need to do so is fairly described as a flaw in the tool.
I've found jira works fine except for two things: 1) it's been around for a long time and still doesn't seem to be a good match for agile and 2) once people drink the kool-aid it starts getting used for everything.
It works great as a todo list of things that need to be done.
But lots of places treat it as the single source of truth and stuff it full with every thing from high-level decisions down to acceptance criteria describing the color of a button.
JIRA is a good way to weed out organisations I will probably not enjoy working with. Kind of like if the interviewer says they have a COBOL or java codebase "they'd like me to look at" even though neither is on my resume.
Ironically this is not a criticism of JIRA itself. I use it now like I'd use a woman's bad hair on a date or her declaring her borderline personality disorder at dinner. It's a form of red flag detection / future horrible incident avoidance.
The problem with agile/scrum and jira is that it is frequently deployed as a form of snake oil with the expectation that it will instantly solve all that ails them. Instead of something that requires actual support, procedures, daily action as well as simple management follow through to succeed.
379 comments
[ 7.9 ms ] story [ 274 ms ] threadI've used Jira for quite a few years at work, and the number one issue with Jira that I have found (and also my team) is that bugs that don't get fixed tend to get lost in the mass of everything registered in Jira.
Jira does try to both be a place to register bugs (and features and other tasks) while also trying to be a place where you organise how the work should be done (eg. with sprints). I guess Bugzilla doesn't do that?
If it isn’t used to track progress or productivity, it contains exactly the right number of entries (since there is no incentive to the contrary). The criteria for closing a ticket are very clear, there is no risk to offend someone by closing their half implemented and ultimately insufficiently detailed entry for example. Bugs are either open or fixed!
The tool does not figure out who should be fixing which bug, that’s the job of the team lead.
When an issue falls on the fence between a feature request and a bug, whoever is allowed to make the call needs to decide and either keep it as a bug, or mark it as wontfix (either out of scope, or to be looked into as a feature).
A well maintained bug tracker is valuable to users, because it comes with a good search implementation (Jira’s search is abysmal for error messages!), and then can work if and when the problem they hit has been fixed. Cluttering that with project management does not help!
Something unforseen is occurring that the spec never talked about and that's reality. (trivial example: if you design without full unicode support you don't explicily SAY in a specification that you aren't supporting some characters, nor would you say you DON'T support such characters). And then a customer comes and says his name shows up as gibberish and you have no tests and no spec mentioning whether this is expected or not. It's simply a case that no one had thought of in neither specification nor implementation. The fact that it wasn't specified makes it easy to say "since we didn't expicitly mention it, it must be a bug".
It's in my experience usually futile to point fingers towards whether something is a bug or a new feature in this case. The customer obviously doesn't care, to him it's just a bug even if it's a lack of a feature (because the customer doesn't have the specification even if one exists). So to the end user it's very much a bug even if to the development team that may have written a spec that says "it shall be iso8859 and garble any utf-8" it is a completely new feature!
And even in the latter case where even the buggy behavior was well-specified, you'd be having a bug report describing the garbled text as a bug. The best you can hope for in a dual bug/feature system is to close the bug report as *wontfix - by design - see feature 123 in the feature tracker 'add unicode support'". This may be a trivial and perhaps obvious example, in most cases these realizations may take a large portion of the time.
Now: a public facing bug-report system feeding into a separate bugs-only-tracker can certainly be useful still, but once those end-user bug reports are converted into work, whether it turns into a workitem in a separate system marked "bug" or one that is marked "feature" isn't really that important. Work has to be prioritized in the same queue anyway. The ROI for fixing a bug, specified or not, has to be weighed against the ROI of adding a feature.
Work tracking is also not the same as bug tracking (or planning!), and it is not obvious that all “work” meaningfully goes into the same queue. A dev lead with a basic grasp of context switching costs and specialised knowledge will instead look at several streams and organise accordingly.
It absolutely makes sense to keep planning separate, if for no other reason than the planning process and details rarely benefit from being exposed directly to the users. Bug reporting and fixing on the other hand is at its best when it is fully open, and is a valuable resource for users.
What's the value of tracking such "bugs" in one of two places, depending on the underlying reason? In either case I might have to get the button to to X in a couple of hours.
Junk article. They also point out that Jira is no longer in all caps but couldn't be bothered to search and replace.
Considering Apple manages to ship pretty decent software, I don't think blaming your tools is really appropriate.
The only real difference from Jira was that despite coming from the Carbon era of design, Radar was much nicer to use because, as a native application, it showed tickets in a regular table view where you could multi-select, drag and drop, etc. I personally find Jira miles more confusing than Radar after having used both extensively.
But that's a fairly minor difference, the design paradigm was the same.
It's largely the Windows team that has a hard time getting its act together.
They don't do that.
That said, I've found myself agreeing with pretty much everything in this article. While I believe that JIRA (if properly configured) can serve as a good issue tracking system, attempts to do top-down, high level planning on it have always left me with nothing but frustration. My advice would be to completely ignore any of these features (e.g. all the "portfolio" add-ons), do high-level planning down to the epic-level in something else like Excel, and then map that to tickets in JIRA. The "Nirvana" of having complete visibility from very high, enterprise executive level planning down to the "what am I as an individual developer working on today" level in one tool is a false idol and just not possible.
We had a weekly meeting where we would be badgered about every >1 unresolved ticket and had to come up with an action plan to make sure it never happened again.
So coincidentally, we would "forget" to create a ticket for every issue, that would take more than a day, until it was one day from completion.
It makes some people cringe in horror but once you start doing that it does wonders.
Combining the original "one open ticket" rule with the second approach is rather bad. That's why I hope it was used in the context of the first approach.
Most of the issues, that took more than one day, couldn't realistically be completed in one day. Waiting on other parties, too many issues at once, low priority, etc.
Occasionally, a ticket about something non-urgent, with no follow up from the business users, would get dredged up from the past to finally get worked on again. But I would attribute that to generally cleaning up unresolved ticket, rather than a benefit of the rule.
I do not believe that what Jira attempts to accomplish is possible. Organizations tend to utilize Jira to automate project management. I see that as a mistake. I want managers and project owners to be forced to keep the entire project in their head as much as is humanly possible. Software development is a messy process with a lot of moving parts and cliffs someone needs to be looking for to avoid going over.
With Jira I see people attempt to essentially automate keeping track of the project and they stop having a high level and deep understanding of the project. I think Jira helps make certain role's jobs easier, as opposed to making them perform better. In shops where Jira is heavily utilized, most developers and managers tend to get in their own little worlds at the expense of the project as a whole. Which again is because not having to worry about the entire project is more comfortable for everyone at the expense of the overall success of the project.
I find that smaller more specific tools solve enough of the problem of project organization and tracking without the side effect I described above.
I know this is a bit of a hot topic and I understand and appreciate that many people do not share my opinion.
Sticking everything in a ticketing system makes keeping a project organized more difficult for the same reason that owning lots of stuff makes keeping your house organized more difficult. There's only so many random odds and ends a person can be expected to keep neatly arranged. Especially if keeping them arranged is tangential to their actual job.
I got a lot more effective at my PM responsibilities, with a lot less time spent doing it, after I laid some ground rules limiting the use of ticketing system on my project. One of the main rules was, if nobody needs to be actively thinking about it right now, it doesn't get a ticket.
I think you should have next 2 sprints of work max in there, probably better if you only make stories for next sprint.
For the meta project/product management I'm just not sure. I'm endlessly frustrated by estimations and burndown charts that never seem to look good. The estimates are always too high, and the burndown charts often look like horizontal lines (sometimes they even go UP). And you can't figure out the cause of that shit by looking at a chart, or even at the board of tickets. You would need to talk to the team to figure that out.
So what do you do for projects that are too big for any single person to hold it all in their head?
JIRA is omnipresent, therefore critique should be taken with grain of salt – you can find complaints about too vague tickets/user stories and complaints about too detailed tickets (with implementation details).
When you choose to use JIRA for something, you are giving up an organizational dynamic where you previously depended on judgement, and you are now handling it with process. Judgement is adaptable but very hard to scale, process is rigid but maybe too easy to scale by fiat (whether it's a good process is a different question).
To be clear I don't mean that your PM's become mindless drones the moment you standardize on JIRA. I mean that where previously your 1-week projects and your 6-week projects would use custom planning processes, now with weekly sprints the 6-week project has to subdivide itself. There may be good reasons to subdivide longer projects, but I think this is an example of the class of problems that come from reality slipping through the cracks of processes.
When you look to JIRA or any other tool for the answer, you have to make sure you are not implicitly giving up the role that judgement plays as the safety release valve for procedural red tape. In that sense it's not even the tools' fault, because you can't blame them for trying. It's that the organization has to see the tool as "just a tool".
Alternatively, this hypothetical tool may be a chain of components/screens/etc. mirroring the various levels in the org. However, I think they would likely provide unusable outputs, because without the precise understanding of how these components build on each other people using the tool wouldn't be able to populate inputs correctly and data may be wrongly classified/consolidated or lost (filtered out) very easily.
There is also infinite flexibility needed for such a tool because as middle management comes and goes they come up with various creative ideas about how to present progress and added value. This may lead to frequent changes in properties that can trickle down to the bottom without any well-defined meaning.
To sum up, I think it would just not be practical.
I've seen heard this opinion a number of times and I don't believe it's true. TargetProcess is a better project tracking tool. It has a deeper hierarchy for organizing work. It has the concept of teams built-in and allows you to view work across multiple teams and/or projects. It also provides a way to do roadmaps built-in. Everything is included and everything is designed to work well together.
As for the specific criticism about not being able to get a high-level and low-level view in one tool, I think the reason why JIRA does poorly at the high-level view is that it has a very shallow hierarchy of work entities. It has epics => user stories => sub tasks. While projects can also be used to organize work, JIRA unfortunately binds the concept of sprints which is more of a team thing to projects. Thus it's difficult for one team to work on multiple projects or multiple teams to work on a single project.
TargetProcess on the other hand has a separate entities for teams and sprints which allows projects to be used for organizing work. It also has an additional level in the work hierarchy providing the following levels: project => epic => feature => user story => task. This deep hierarchy allows you to group work into larger groups allowing you to see both the high-level and the low-level.
https://www.targetprocess.com
Portfolio allows for multiple layers on top of epics. Boards can be set up to pull from multiple projects, and boards are what are tied to sprints, projects are not tied to sprints (mostly, there’s some oddities).
Portfolio is implemented somewhat badly (Why the hell can’t I do skip level relationships?) but it certainly has the features you say you’re lacking.
I believe this has been fixed for some time.
https://community.atlassian.com/t5/Jira-questions/How-do-I-c...
https://community.atlassian.com/t5/Jira-questions/combining-...
I agree about the too small number of hierarchical nesting though.
Having a few extra levels of issue types in jira would be nice, but if you treat epics like TP features, you can use portfolio to add however many layers the PM and management team want on top.
JIRA is heavy and slow - it's model of limited transitions is fundamentally flawed, encouraging micromanagement and making mistakes hard to undo. But a lightweight board that you push tickets through - the famous "kanban" - is a great way to develop software (I've had a lot of success with Trello, though I fear it's only a matter of time before Atlassian bloats it into JIRAness).
Trello adds unlimited wall space and a distributed wall. If you don't have lots of remote workers, and the wall is big enough, then use it. There is something wonderfully tactile about chatting in front of a real kanban wall when working out priorities. At the next checkpoint/sprint meeting, you can physically add cards to your backlog. Physically push things up the priority list. I love it!
I like 5×3 index cards better than post-it notes..
The concept of epic/subtasks is missing. So if a ticket becomes to big, and you want to keep the history while breaking it up, requires a boat load of copy/paste.
Also, there is a trend to have a physical board with tickets, as well as a trello board. This was fashionable amongst the scrum masters at previous large employer. It was universally hates as we had to spend loads of time playing with physical cards, then try and copy the state into the ticketing system. Its was annoying and a massive waste of time for everyone.
Especially as it didn't encourage people to write the work they've done on the ticket, to allow it to be taken up by someone new.
Oh no! This sounds like a horrible idea! Two sources of truth, everybody trying to avoid the work of syncing them. Eek.
> The problem with trello is linking tickets intelligently is hard.
One way is to break any sizeable task onto it's own board. Just note on the card that it has been moved to a board of it's own. There is a logical team>board structure for this. Then you have a master board with the main building blocks on it, and then sub boards with tasks/stories on them. It is no panacea, but it can work
We've experimented with this type of thing in my company. In practice, we found that having multiple boards for a single project is just a bit too much to keep track of.
I could see this working if Trello made it easy to quickly move between boards. This could be something as simple as a breadcrumb style path: Grandparent Board > Parent Board > Child Board, or something to that effect.
Or maybe that would overcomplicate Trello, I'm not sure.
Bollocks.
The "highest priority is to satisfy the customer through early and continuous delivery of valuable software."
Not tickets, small or otherwise. Not tasks. It has nothing to do with two-weeks.
> Ignoring the "wider vision" is the best way to produce software that actually solves people's problems
I have no idea what you could possibly mean by this.
Every time I've ever seen a modular development that isolates developers from the business (or from each other), I've seen brittle software, and that's assuming they get done at all.
> But a lightweight board that you push tickets through - the famous "kanban" - is a great way to develop software (I've had a lot of success with Trello, though I fear it's only a matter of time before Atlassian bloats it into JIRAness).
Listen, if software helps you, then great, but if your whole life is "pushing tickets", you're not doing Agile. It doesn't matter if you're using Jira or Jello.
https://agilemanifesto.org/principles.html
https://www.youtube.com/watch?v=a-BOSpxYJ9M
I like Jira. It's terrible, of course, but way better than using nothing. Tech Crunch is mainly criticizing how "Agile" development is commonly used, to micromanage and give a false sense of grasp of the scope of a project for management. Micromanagement without the responsibilities coming with micromanagement (providing nice specifications, doing follow ups, taking responsibility for failures, etc) make me miss the waterfall model ...
To me, Agile is really a set of principles to help you decide what to focus on (e.g people over processes). The different methodologies (scrum, kanban, etc) are just frameworks to help you build the best dev process for your team while trying to keep the agile principles front and center.
In reality, all kinds of factors get in the way of True Agile - experience of devs, team dynamics, company incentive structure, management expectations, management’s management expectations, how the company handles failure and the subsequent ownership vs finger pointing, etc. The actual implementation of Agile should be different for each organization because the environment in which they operate in is different. With that said, there are certain core principles and practices that are very beneficial across the board and consistency across teams within an organization certainly helps.
I think agile is fundamentally simple. The essence is the continual improvement. How that translates into a working process (like when do I write tests and who updated the docs) are going to vary project to project.
Just what do you think "early and continuous delivery of valuable software" looks like in practice then?
> Every time I've ever seen a modular development that isolates developers from the business (or from each other), I've seen brittle software
Completely agreed. I've found any "vision of the project as a whole" is exactly where that isolation tends to happen: once this "skeleton of the city" is laid out, business input gets cut out because The Plan has already been agreed.
> Listen, if software helps you, then great, but if your whole life is "pushing tickets", you're not doing Agile. It doesn't matter if you're using Jira or Jello.
Nonsense. Again, how better to achieve "early and continuous delivery of valuable software"?
By building an application and putting it in the hands of the business as often as possible.
Thirty years ago I used a whiteboard.
I never needed ticketing software to build software or to ship software.
The only time I ever used ticketing software (from the contributor side of the fence) is when the business I was working for wanted it, and the only thing they ever did with it was track my time. Good for them.
Now when I'm on the management-side of the fence, I still don't really like ticketing software. I use Jira because the rest of their business uses Jira, and they want accurate reporting for R&D tax credits and doing KPI-based bonus remittal, and they've built reports and scripts on top of Jira. Some of my developers like to use the tickets themselves, and some prefer to let my assistant do the ticket busywork.
I'd buy the developer package.
Do you give the VA their own JIRA login? Or can we make a browser extension that lets the VA use yours (or mine)?
(My contact details are in my HN profile if you want to discuss)
Just putting the application in the hands of the business is not enough, you need to ensure that you're actually delivering value to the business. You need pieces of functionality that you know the business values (and where both sides understand what the valuable thing is) - i.e. tickets.
> Thirty years ago I used a whiteboard.
> I never needed ticketing software to build software or to ship software.
I'm sure I could keep it all in my head, but I'd rather spend that mental capacity on more important things. That you found a whiteboard useful says that tooling can be helpful - and Trello can be more convenient than a physical whiteboard.
Yes, it really is. There is so much software that has been built without a ticket system. If you need examples, just ask!
Tickets can be a proxy for business value, in a way that a checkbook is a proxy for money, but it’s not the checkbook that pays salaries: Software is built in the brain.
Doesn't the checkbook of a business literally pay salaries? I'm unclear as to what you're arguing here.
Hint: Some businesses don't even use checkbooks.
> I'm unclear as to what you're arguing here.
Is it really unclear?
Having small-scale tickets that you actually finish is the very essence of agile
This I disagree with. "lmm" seems to think that tickets are either "the very essence of agile" or perhaps even essential to "deliver value to the business."
But is this because the developers want that, or because management has carved in stone The Schedule, based on The Plan, and the only way for dev to stay on that schedule is to reject updates?
"The #1 software development tool used by agile teams"
and
"The best software teams ship early and often."
and
"Development workflow: Jira Software automatically updates issues and transitions work when code is committed in Bitbucket."
and
"Continuous integration: Power your CI with Bamboo and monitor build statuses without ever leaving Jira Software."
(That last sentence is nightmarish.)
I think a lot of people believe that it's their tools that make them able and forget it's their brains that use and make the tools.
I also think that anyone who thinks using a particular tool is essential (as opposed to meritorious) needs to get their head examined.
Do you have any details about your emacs/jira workflow?
Not my experience. The most important way to get flexible architecture is simplicity - not having things you don't need. More often than not, architecture designed for some kind of flexibility up front turns out to impede flexibility in a different direction (which was actually what was needed) where a more naive design would have been fine.
The detail level and task breakdown which is appropriate for planning which features you'll prioritize and do for a sprint may not be a good task breakdown for actually assigning sub-tasks for people, looking at their progress/status during a sprint, and mapping particular commits or hours worked to them. JIRA common practices sort of force those things to be the same, which may be considered harmful.
To use their metaphor. The airport gets a ticket. Then you put another ticket up that says 'find a good field to land in', then another that says 'level out field for x class of plane', then another that says 'install basic lights'etc.
Things are now getting marked complete and you are agile all over again.
In this example you could for instance create 'Airport' as an task and just write on it that you are going to aim for a dirt strip first and are going to start a separate task for this.
This is the power and weakness of Trello, there is no link! Except of course you can create a new board called 'dirt-strip'
Breaking things down appropriately is, in my mind, 80% of the work. If you have your head straight, the implementation is easy; but it can take implementing virtually the entire thing to get your head straight.
Don't break out later stages too early then! Just enough to get to MVP. That is the essence of agile and XP isn't it?
Seems to fit your needs then!
And if your developers don't have a bigger picture understanding then they also won't know that there are already runways they should be using.
It seems to me that it’s slow on a number of levels. It just takes a long time to load each page, and on top of that, basic operations usually take far too many clicks. So I figured it was just a bad tool.
It's a spawling Java app with hundreds of discrete components, aging plugin architecture and is susceptible to configuration creep.
(That seems to be my impression, at least).
Things I've seen that can adversely affect your speed: installing random plugins that are poorly written, integrations, having too many admins over-complicating the Jira configuration.
Learn the keyboard shortcuts to speed up your basic operations.
Are you on an onprem version?
https://clickup.com/
It's like they spent much more time refining the UX and feel of moving around clicking on things. It's pretty great.
I just gave it a whirl - for an hour or so - so take this with a grain of salt.
Looks much nicer, and there definately has been more effort put into the design compared to trello / jira.
Thats about where things end for me though.
I don't think the UX is refined at all, it's full of usability faux pas and their CSS could undergo some basic usability testing as well.
Jira's usability isn't that bad if you use sane defaults and avoid overconfiguration. Jiras main problem (and its a big fucking problem) is responsiveness.
I did have a look at their suggestion forum and it looks very active I think I'll give them another look in a few months to see if they've managed to reign in some of the BS or if it only gets worse. (I suspect the latter will occur for various reasons.)
And please, don't take this harsh critique the wrong way, if I was choosing a platform today I'd probably pick them, beauty is a hell of a drug - just don't confuse a nice looking design with UX.
[...]
But it is a tool deeply ill-suited to be the map of a project’s overall vision or infrastructure, and it is never the source of truth — the source of truth is always the running code.
I'm not sure what Jon Evans means by "prose" to document the "macro vision"... a freeform text file? MS Word doc?
Personally, I need more structure than that so I use a spreadsheet for it. I like to create columns of metadata to assign a priority, notes about difficulty, estimated time, estimated cost, etc. Any large project will have hundreds of wishlist features that need to be organized. Prose is too unstructured for that. Maybe JIRA is too bureaucratic and the wrong tool too; I'm not familiar with its goal-planning tools.
I can't store the "macro vision" directly in source code because many wishlist goals are greater in scope than placing a commented out line in a cpp file such as "//TODO:implement voice recognition."
Yes, the source code is a "source of truth" but it's only truthful at the abstraction level of generating an executable. It's the wrong abstraction for gathering wishlists, future goals, and priorities.
Yes. Sometimes.
> Personally, I need more structure than that so I use a spreadsheet for it. I like to create columns of metadata to assign a priority, notes about difficulty, estimated time, estimated cost, etc.
I think having a spreadsheet is good too.
This isn't either/or.
> Yes, the source code is a "source of truth" but it's only truthful at the abstraction level of generating an executable. It's the wrong abstraction for gathering wishlists and future goals and priorities.
I don't think that's what is meant by this statement: the source of truth is always the running code. I read it a call for an iterative and evolving "design" that comes from the program as it is run, instead of some repository of code or tickets.
To engage with JE's particular essay, I think it is either /or. He emphasized "prose" with italics. Seems a reasonable interpretation is that he thinks the rigid or incorrect structure in Jira is wrong to document a macro vision. If he thinks another structured tool like MS Excel or MS Project is a desirable alternative, it seems he would have mentioned it. Instead, he recommends prose.
To be pedantic, one can type "prose" right into Jira. But that would be an uncharitable reading of his essay. Therefore, he must mean something else: a document that's more freeform.
>I read it a call for an iterative and evolving "design" that comes from the program as it is run
If he meant that, he's wrong because the running program is always an incomplete picture of what you desire the program to do. The "desires, goals, and design" -- ultimately has to be stored outside of the source code and therefore, it can't be a source of truth for that type of macro vision.
(Yes, there is a school of thought that proposes that "the source code _is_ the design" but I've always seen that as more of a reaction to UML diagrams and flowcharts from CASE tools that get out of sync with the actual code. To really fulfill the "code is design", it would require an extremely powerful declarative language compiler that turns high-level English specifications into executable code. Using today's primitive languages such as cpp and h files isn't a good way to express "code is design".)
Yes, the macro-level view belongs in prose. In a word-doc perhaps.
All I meant was that this doesn't preclude the use of tools like Excel (or Jira) to break up tasks into items and estimate their cost. If you like doing that, then great: you're not doing anything wrong.
Weren't really considering jira, but would love to hear any suggestions.
And, I'm not a fan of Jira.
But, the difficulties noted in the article feel wrongly assigned to Jira. They aren't Jira's fault. It's a process problem of the org using Jira. A deficiency in the way projects are architected, documented, and communicated about. It's not the tool itself that is the problem.
Tools and process work together to create a production system. When the system fails both share blame.
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.
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."
Implicit in this is the assumption that you're not scared of redoing the internals or redesigning the UI as you add features.
It's not about changing the interface frequently. It's about changing it poorly.
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.
"Unless you're scared of a little moving fast and breaking things."
It's a common pattern. When a software system becomes complicated and fragile, it's quite common for the developers to get scared of breakage and move slowly.
Sometimes there are fundamental reasons for moving cautiously, and sometimes they're accidental reasons that could be fixed with a better process (such as better tests). Either way, just being more reckless isn't going to help.
So if you had in mind a generic upload UI where it would look weird with only one choice in the menu, then better to skip the menu entirely for now. It makes the UI worse, and implementing the menu is more work. Plus you don't want to end up with dead code lying around if plans change, since that could confuse someone later.
But if none of those considerations apply and the generic version is actually easier to implement and the UI is just as good, sure it's fine.
> 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.
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.
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/
I'm used to use Jira only for timesheet purposes: hierarchical decomposition (project X, activity Y, often also employee Z) allows stress-free accurate accounting.
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-ebe...
that's not true. an experienced developer will actually structure the project in a good way, even if the problem is split into multiple issues.
If a person repeated the same project 5 times on the last attempt would require very little trying to find the proper structure. Experience has everything to do with that.
After a number of iterations of this, you converge on a baseline architecture that you try to support future change without being excessively focused on YAGNI. Over-focus on YAGNI often leads to architectures that are so inflexible that when you DO need it, you can't add it without a demolition crew[1].
People should also remember the context in which YAGNI came up: Kent Beck, Ward Cunningham, Smalltalk, and the C3 project. This particular combination of people, project, and process made YAGNI feasible. And the C3 project, which spawned XP, was not as successful as folklore would have it[2].
It's not always so. Imagine if YAGNI was the focus of Roy Fielding and the HTTP specification, which has lasted remarkably well because of allowance for future change in the architecture.
Scrum and other processes that claim adherence to the Agile Manifesto work best in certain contexts, where code turnaround can be fast, mistakes do not take the company down and fixes can be redeployed quickly and easily, the requirements are not well-understood and change rapidly, and the architecture is not overly complex.
Many other projects don't fit this model, and people seem to think that so-called "Agile" (which even the creators of the Manifesto complain is not a noun), and mostly Scrum, is the sole exemplar of productivity.
The fact is that there are many hybrid development processes, described by Steve McConnell[3] long before the word "agile" became a synonym for "success", that may be more suitable to projects that have different dynamics.
An example of such a project could be one that does have well-defined requirements (e.g. implementing something based on an international standard) and will suffer from a pure "User Story" approach.
Let's be much more flexible about how we decide to develop, and accept that you need to tailor the approach to the nature of the project, based on risk factors, longevity, and other factors, and not on dogma.
And let's not underplay the extreme importance of a well-thought out architecture in all but the most trivial of projects.
[1]: https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it
[2]: https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens...
[3]: https://www.amazon.com/Rapid-Development-Taming-Software-Sch...
https://agileforall.com/resources/how-to-split-a-user-story/
The article may have a clickbait headline, but „have an overview and use JIRA in addition to track the leafs of the work hierarchy“ is true.
What I found is that almost all projects try to organize as tree but they should organize as matrix, at least if there are many cross-cutting components.
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.
https://news.ycombinator.com/item?id=18608294
It needs half a terabyte of RAM to open.
I would still love it if user stories were implemented as the "why" (or even "what") instead of "how", though.
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.
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.
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?
"This rough implementation is how I (we) envision this feature working. What do you think?"
"We've got the feature working well but it requires non-trivial back end changes. Would you be willing to wait or will you be satisfied if it works but only in a very manual way until we get the back end changes in place?"
Week 2 after release: "The feature is live... What do you think? How is it working?"
These are conversations the developers should be having with the end users. Regularly! It's when developers only ever talk to their boss and/or the project manager that pushes development into the anti-user zone.
https://www.railinc.com/rportal/documents/18/260641/Guidefor...
The software for it has to work. There will be months of work implementing the rules engine before you have anything to show the customer besides a mock-up..
You won’t really need two week sprints to get feedback from customers. It either implements all of the rules or it doesn’t. I can imagine the same happening for tax software.
If a customer isn't committed to the project, then I'd worry about committing to it as well. Even if the contract guaranteed I'll get paid, there are few things as demoralising as a project falling over because, once push came to shove, the customer didn't even have the manpower to deploy your product. Those are usually the same people who would do the evaluation, so with my experience, as an employee, if they're not there, I'm going to look for a project where they are — regardless of how confident sales might be.
Well, by definition, a feature that takes 2 months to build takes 2 months to build. Shipping part of the feature early doesn't provide feedback for the finished product. It provides feedback for the incomplete feature. How valuable is that feature?
In addition to that,a feature that takes 2 months to build will take longer if you are releasing multiple sub versions. You have to account for actually making it production ready, and releasing it, and handling errors and feedback.
This is why experience matter. Was your feeling of control and happiness worth shipping half-finished, substandard product to your customers?
Then all four developers would have had to coordinate with the Devops guy.
This is all getting into “Mythical Man Month” territory.
Instead of me trying to explain it, I might as well crib the explanation from Wikipedia.
Complex programming projects cannot be perfectly partitioned into discrete tasks that can be worked on without communication between the workers and without establishing a set of complex interrelationships between tasks and the workers performing them.
Four equally qualified people should be able to deliver more features in the same amount of time working independently than four people working together.
When I was a team lead, I made it part of the “definition of done” that you had to have documentation and knowledge sharing. Now, I still have both an overview of my proposed architecture before I start just to make sure I didn’t miss anything, Visio diagrams,Powerpoint slides, wiki documentation, an “architecture review”, etc. I hold myself to the same standards I held anyone on the team to.
From a career development standpoint, software developers are a dime a dozen. It’s the people who know how to communicate effectively are the ones that get ahead.
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.
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.)
You could also say to switch up what scrum means if you're having trouble -- to be honest I've never considered the idea of just ending the sprint early (and rescheduling the sprint planning meeting!), I'm skeptical than any of the "Certified Scrum Masters" I know have either... But it still can't be done if you are finished early but the rest of the team isn't. My team didn't really have a problem with taking on work assigned to someone else so long as that work wasn't started yet, but things get tricky when all the work assigned has been started by someone. A solution in that case does present itself besides just bringing in something new, it's the same solution as kanban when the buckets are full: join another developer on their story and pair (doesn't have to be "formal" pairing even) to get it done faster.
But you've highlighted another problem with the whole mess, that being ownership accountability. Lack of visibility outside of the standup meeting into what Dev B is working on when they're paring with Dev A (who is the sole "assigned dev" in the tracking system) is an obstacle to incentivizing pairing. Sometimes you need that visibility. On an old team I left because of terrible management, there were just two of us devs at one point. One sprint it turned out that my face was on the dev column for almost all the items, the sprint before it was my coworker's face, in reality we paired on almost everything. But that second week my manager (who never joined our standups) asked "What are your thoughts about Dev A's work performance? You seem to be doing everything right now." Management memory was sprint-to-sprint. This isn't a problem with scrum, of course, though it does enable that problem to surface where at least in a kanban style you'd have the giant column of closed things having a mix of faces.
What I have seen mostly, is that the devs finish early (about 1/2 or 3/4 into the sprint), and wait for QA. And so, QA is idle at the start of the sprint. Bleed-over was then just accepted and incorporated, while I was not sure of the usefulness of "sprints" anymore.
I'm not sure about "agile." In my experience, "agile" means "we have no workflow and it's a fucking madhouse."
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.
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.
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.
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
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.
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.
> 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.
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-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.
None of this "button here" "wire it up later" "now add the db table" etc.
Complex tasks are incredibly hard to finish as a single ticket – with such granularity you might have opaque progress for couple days, and you hide a lot of details from everyone.
Unless you mean "tickets" as "user stories", they can be (although not always) treated like that.
Yeah - entirely depends on your subdivision vernacular. Some people make subtasks in a ticket, some people make tickets linked to other tickets, some people do both and link those to "features" which are themselves tickets (like the environment I work in).
Just depends!
It is very hard. At my last gig, we got to a generally good state where the PMs were responsible for periodically outlining their overall "vision" to the team, which captured what we're building and why we're building it. In stories, PMs were made to be very focused on focusing on "what", not "how", and to provide the context for "why". That let the PMs stay out of technical details and let the Engineers use their brains to fill in gaps.
It took some pain and effort to get to that point, but once we got there, it worked very well.
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.
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.
A finished product can be sold ethically, a prototype cannot.
Sounds like a process problem and communication breakdown, not a JIRA issue. We use JIRA and it isn't like that at all.
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.
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.
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.
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?
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
But experts are fallible, and distractions are many, and sometimes even experts get lazy or confused or overwhelmed.
it says it was created in 2002
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.
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.
The author uses a flawed analogy to push a flawed argument.
Jira is a tool to track what stuff needs to be done. Using the author's city analogy, they appear to be advocating that all city workers need to have a vision of the whole city plan for any task they they are doing, that doesn't scale.
Large projects are to big to fit all the detail in one person's head. Design goals are broken up, issued to specialist teams, which then break them up again.
To then blame the tool for worker not bothering to understand what they are working on is not the fault of the tool, its the fault of the worker.
Ok smart arse, how do _you_ use Jira then?
Simple, its a big arsed multidimensional to-do list. There are a set of business goals with solid business deliverables(which of course translates into vague tech targets) Each team is assigned high level tasks. Its up to them to split them up and write down _what_ they want to do, and then in small subtasks _how_ they are doing it.
if they are too stupid to ask "how does this align the business need?" then they shouldn't be allowed grown-up scissors. (why are you hiring them?)
For most projects, it does scale. The problem with almost all software development analogies is that they attempt to draw parallels between design and manufacturing. Software development is much more design than manufacturing.
A more suitable analogy would be art. Imagine a group of artists commissioned to create a painting. The designers decide, upfront, the main elements of the painting, then someone else breaks the work down into tickets based on those elements.
Unless extremely well managed, the result is likely to be hideous and the project is likely to have a high turnover of artists. This is pretty much what happens in most software projects. The real problem, as this article identified, is that a bigger picture perspective is needed. Unless a project is crystal clear about the big picture, everyone will have their own big picture and build features accordingly.
Also construction.
The way I see it, what programmers do is not constructing a building, they're doing the architecture (and wiring plans, and landscape plans). Construction is what compilers do.
Later on in the pipeline, the modelers, animators, lighters, texturers all have to take the storyboard input, combine it with the vocal cues and make an artistic thing.
There is an agreed upon style guide, with a very close feedback loop (dailies, weeklies and monthlies). all managed by something like https://www.shotgunsoftware.com/ or ftrack. which is basically Jira + MS project love child.
Its the same with software, There is a style guide (well should be, you can use this tech, with these standards, deployed and monitored by these tools) which lives outside of Jira. Jira is then both tracking tool (so the buisness can see progress) planning tool, so that decisions can be traced, tracked and adjusted, and notebook.
I can understand the hate for Jira. I was at a company where we changed workflow every sprint. Its dispiriting, annoying and wasted on average .75 of a day a week. Thats not the fault of Jira, that the fault of the people who take the religion of AGILE and impose it.
Process should be mapped to the system, not the system mapped to the process.
They are "the worst except for all the others".
If you really are a huge enterprisey team that has many levels of visibility for various management levels and stakeholders, as well as large distributed teams working with different schedules and modules, then github tags or post-it notes eventually won't cut it. They are nice and streamlined for a while, but then someone will ask for a weekly report of X or a website showing progress Y and a corollary to my main argument is that someone is always to oblige with the request even though the correct answer may be "no! Let us just use streamlined tools and just make smaller independent teams!".
And in the end if you start off with post-its, the github issue tracker or some lightweight issue management system you'll end up according to this theorem:
Every software project management system in a large enterprise environment that isn't already a large enterprise one (like Jira), will eventually become an ad-hoc, informally-specified implementation of Jira.
Even SCCS supported something called "modification request" numbers. These could optionally be checked by an external executable, tracing each commit back to a ticket number.
Storymapping isn't a perfect tool for sharing product vision, and by trying to be storymapping+estimation+progress tracking, Vistimo is of course imperfect at each of those things individually; but having the combination has done me and my clients a lot of good.
You can create a design ticket where you describe the larger overall picture (city planning) and then as you implement it, add enhancements (neighbourhoods and sewers) as subtasks. If something breaks when you add the enhancement, for example a memory leak when calling method X, you can create a bug ticket that only concerns the micro details.
Nowadays, Agile/Scrum is a buzz word, every company is trying to get it, but rare people understand it. They buy tools (like JIRA), they do standups, they assign story points...and then things become messy and it all turns into into a glorified waterfally kanban with story points.
JIRA is just a tool (bloated, maybe), nothing wrong with it. Personally, I find it to be OK -- no major complaints about it.
The only thing that came out of it was a big word document that looked like the big word docs id write for waterfall back in the day.
I don't think people realise just how little things like JIRA and Trello do for you.
The only thing they can give you is a different view of that same word document.
The second they over clutter themselves with junk in the interface and custom flows the benefit to using them is lost.
Trello is a good example, it used to be pretty decent. Now it takes something like 10 clicks to delete a card.
The rest of their interface is chock full of antipatterns like that.
Someone needs to build something that does one thing well and doesn't try to do every other thing under the sun.
As an example: I recently ran a small engineering org (started out with just me, grew to about ten eng) working on a Python system. The founders had a lot of trouble sourcing, so we ended up with engineers that ranged from okay to mediocre to terrible. There's a ton of dangerous Python footguns that competent engineers have the discipline to avoid; engineering in Python at Google isn't exactly fun, but it's workable. OTOH, trying to run an engineering system in Python with the kind of engineers at this last company is a constant nightmare of catching and stopping idiotic abuses of Python's flexibility. Using something like Java would have imposed discipline on this engineers for a subset of the mistakes they were making. While it's true that sufficiently skilled engineers would've been aware of Python's pitfalls and worked around them, it's entirely fair to say that this permissiveness is a downside of engineering systems in Python.
As another example, I feel exactly the same way about Facebook: for all the talk about how usage makes you depressed and scrolling through the newsfeed is bad for your mental health, I'm able to use it as a messaging, photo sharing, and event planning platform and can't remember the last time I looked at the news feed. That doesn't mean that it's unfair to criticize Facebook for the effect it has on those who can't resist doing so.
To put it more concisely: while it's true that smart/competent people can think critically about the weaknesses of their tools and work around them, the need to do so is fairly described as a flaw in the tool.
It works great as a todo list of things that need to be done.
But lots of places treat it as the single source of truth and stuff it full with every thing from high-level decisions down to acceptance criteria describing the color of a button.
Ironically this is not a criticism of JIRA itself. I use it now like I'd use a woman's bad hair on a date or her declaring her borderline personality disorder at dinner. It's a form of red flag detection / future horrible incident avoidance.
The problem with agile/scrum and jira is that it is frequently deployed as a form of snake oil with the expectation that it will instantly solve all that ails them. Instead of something that requires actual support, procedures, daily action as well as simple management follow through to succeed.