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.
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..
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.
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.
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.
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.
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/
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.
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.
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.
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.
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?
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.
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.
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.
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.
> 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.
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?
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.
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.
> 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.
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 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:
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.
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.
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.
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.
> 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.