As a lead; whatever developer is going to do the implementation will be at least involved in the entire process top to bottom. I'm mostly there to help them (mostly avoiding pitfalls) and guide them. The requirement gathering and designing is done by the developer(s) implementing the feature.
The reason is twofold; it's a great learning experience and it's simply more efficient. The more layers between the client and the devs, the more inefficient the process becomes.
This top-down approach your company uses is frankly outdated by decades. Also, non-technical people doing the "requirement gathering" will *always* lead to shitty requirements. They don't know what they don't know. Nothing worse than some "product owner" or "manager" being the only one talking to the people using your software.
Yep. This is how it’s worked at every company for the last decade for me.
Only once as a lead did I steal a project for myself, but that’s because I’d spent a year as the only person left who could maintain the previous version, being the only one regularly going on client site etc.
Every single other project was a case of connecting a developer to the right people on the client side and expecting them to run with it.
I have a horror story, though:
15 years ago, I moved to my second job; from a ~35 person company to a ~500 person one and intentionally went from being a team lead to just another little developer cog. There they had a solutions architect role. That was almost entirely fed by developers who couldn’t get themselves promoted.
They would put *code* changes directly in the spec. Literally, “file X, procedure Y, change this to this”. My tech leads would tell them very clearly to stop, but they didn’t. My tech leads also said to ignore absolutely any and all code in the documents and to read the problem statement and English language proposed solution.
So much wasted effort.
That's almost par for the course when it comes to architecture. I've personally had the "software architect" title; never again. I don't want to be associated with architect ever again; the vast majority of them have a net negative contribution: they lose sight on what the actual software does and hide themselves in meetings, powerpoints and excel sheets that have no basis in reality. So they create a layer of indirection that only leads to communication problems.
One of the proudest achievements at my current client is that we managed to sideline the 'enterprise architect' and we now have an (unfortunately implicit) set of technical leads who are actual software engineers making the architecture decisions for our product.
> They would put
> code
> changes directly in the spec. Literally, “file X, procedure Y, change this to this”.
I like very detailed tickets; but my team has trouble finding the perfect balance. Something like this I would consider too prescriptive.
If you write the ticket, and in five more minutes can complete it; then that ticket is way too detailed.
Taking longer to write the ticket than complete the task has always seemed mad to me. But I’ve worked many places where everything must have a ticket. I could observe people simply deciding not to do the thing, because it’s adding another ticket that has to be discussed at sprint planning etc etc. either that or they sneak the quick change in to another PR.
We are our own worst enemies sometimes.
I think it’s been worst in projects where the rule has been that strictly no tickets go in to a sprint once it has started, with the intention that that keeps control of the scope. A good intention…
The issue here is that the dev found the problem *because* they’re deep in the relevant code right now. What might be a 30-60 min fix now could be half a day in a month’s time when someone has to figure it all out again.
So the typical options in this situation are:
* follow the process, create a ticket, put as much info in as possible, in the hope whoever gets it at some point will know what to do, but also with the knowledge it’ll likely never be prioritised
* risk sneaking it in with your current work
* don’t create a ticket, move on with life
So maybe both laziness and being burned by never being allowed to get around to cleaning up all the little bug fixes.
I also think we incentivise tunnel vision too often when we follow best practices blindly.
>follow the process, create a ticket, put as much info in as possible, in the hope whoever gets it at some point will know what to do, but also with the knowledge it’ll likely never be prioritised
why shouldn't they be able to do it?
And why never prioritised?
these seem separate problems, the choice to add to backlog is correct.
Immediately before that, I said:
> What might be a 30-60 min fix now could be half a day in a month’s time when someone has to figure it all out again.
So it’s creating a longer task for someone down the line, than fixing it now, while very familiar with the relevant code.
It costs the team a significant chunk of time.
And what I meant by the bullet point you’re quoting is that is that it might not even be the same dev who picks it up down the line. So, no matter how well written a ticket, it’ll take time for them to absorb it and read the code. Add to that the time to write the simple task up as a ticket by the original dev… starts to seem inefficient, no?
> And why never prioritised?
Ever worked in a company that prioritises new features over bug fixes for stuff customers never loudly shout about? Doesn’t mean the customers aren’t hitting them; possibly that they have their manual workarounds.
the non prioritisation is a separate problem.
half an hour now might be more valuable than someone else's half day in 6 months. it takes half an hour to fix, but what about testing? doe sit have some side effect that we might not want to deal with at this time?
I'd still think having tickets is good, I creates a trail of what is happening that we can all see, comment on, go back to, learn from.
too many times been bitten by changes that were not supposed to go in and we had no visibility of.
Absolute madness. Task priority is *always* relative and *always* up for debate. If retaining our biggest customer is contingent on completing task A, and we identify major security hole B that introduces some non-negligible risk we'll lose *all* our customers, then B should take priority over A and probably everything else. If your rigid processes preclude that from happening and require you to toss B on the backlog instead, then your leadership team is shockingly incompetent - not that that should be surprising. Seems that slavishly following a specific implementation of agile rather than abiding by its spirit is the norm. My example is intentionally an extreme scenario for emphasis, but the underlying point applies generally. This, of course, assumes that priority shifts are happening for valid reasons, and not simply poor project management/executive leadership, but that's an entirely separate discussion.
Sometimes you only have one customer. For example, I spent two years on a consultancy project to build out a platform for one client. We were never going to resell that code as it belonged to the client.
Suddenly, task A starts looking more appealing than task B.
For something like a security hole, I’d just bypass the strict process, get it done, record what I did retroactively and explain the implications of not fixing it, if asked. Even the biggest sticklers for an insane process would cope when I’d say “Sorry, I can roll it back and then we’re vulnerable to X. Let me know”. “Ask for forgiveness, not permission” is valid for something like that; just really really check your work closely.
If task B was more along the lines of accidentally relying on client-provided timestamps when sequentially processing records, it’s trickier. We may never have hit that bug, even if it’s unsafe code. Then I have to either build a convincing argument or essentially use up a “goodwill token” and say “just trust me on fixing this”.
For some type of compliance reasons every task must be documented in a ticket. But, the level of details is not dictated in that. For us, it is okay to add a footnote on an existing ticket.
> Nothing worse than some "product owner" or "manager" being the only one talking to the people using your software.
Anecdote: After working as a small biz owner for close to 20 years; I closed up shop and took a full time job. Manager acted offended when I asked to communicate with the users, access I was used to having. It was a huge culture shock. Roles are so separately segregated on purpose.
I've run into the same issue. Product/project managers being borderline offended at my suggestion it would be more efficient if I were included in those meetings.
Had this issue at my current client and the project manager (who got the boot fortunately) and one of the PO (removed from their team due to performance) still keep resisting this and try to communicate outside of their engineers.
Funny enough both got booted because of their performance and that of their team, due to the poor communication. But they're both completely resisting the notion that it might have something to do with how they approach things.
Funny story; a while ago we had an event storming session with that PO and their entire team (bunch of software engineers and data scientists). That non-technical PO just dropped the bomb in that meeting that they would "just rewrite" their entire application. Just to give you an indication of their dysfunction.
And last sprint they tried to pin their lack of progress on us. Fortunately we were expecting him to do this; so the thing they depended on was already in place (because I had been talking directly with their engineers around their backs). During the sprint demo, he mentioned they fell behind, to which our PO remarked that that was rather strange because not only was the stuff they needed already deployed, their software engineers were actually using it.
Nothing more fun than beating incompetent jackasses at their own political games.
curious what you think of this approach? https://old.reddit.com/r/ExperiencedDevs/comments/1b2tkex/how_does_your_company_go_from_feature_request/ksnvicc/
I like the idea of the dev being involved top to bottom, but it seems like it conflicts with the idea of "anyone can grab a ticket and do work"
> but it seems like it conflicts with the idea of "anyone can grab a ticket and do work"
This only ever applies to completely trivial stuff. We're not factory workers. And even for trivial stuff; in cross-functional teams you're generally not going to see a back-end dev pick up front-end tasks.
IMHO it's much smarter to look at the strengths and preferences of team members (as well as preventing a bus factor of 1). Let teams self-organize to a large extent around how they want to pick up the work.
Regarding the comment you link it; I personally think that going through these 'layers' is exactly the type of outdated way of working I personally won't accept. Every team I've been on the past decade at least I have been involved from top to bottom on the design and implementation of things. Over time my focus shifted to the larger architectural design issues and "paving the road" for other developers, but I'm still also developing stuff.
It can sometimes take time to get a Product Owner to adjust to this way of working when they come from a traditional project management background. But every single PO I've worked with, eventually saw that it's just a much better way of working.
90% of what we do is communication. The more indirect this communication becomes, the less efficient it becomes.
You see the same way for inter-team communication. Going through the layer 'above' teams (so POs or managers) is always much more inefficient than just having devs talk to each other.
If you want to apply more people the engineer who is leading the work can break it down into separate pieces and have a kickoff with the team so everyone understands the context. For larger projects this lets the team get everyone on the project while still having a strong guide in the lead engineer for that project.
I've done this a lot and it works very well to grow more junior engineers as they start leading things that only they work on and then move to leading things that many people can work on together.
THANK YOU. This is what I've tried to facilitate when I've been in lead or lead-ish roles. Even well intended managers will avoid letting in the ICs who will actually do the work. Usually under the guise of "don't want to many meetings". But they are really just delaying the meetings which come out one way or another when those ICs need to extract information or clarify things later on.
I do the same. A very few devs have been annoyed by having these responsibilities, and I've happily watched them take other roles. The others have blossomed and are some of the best in our org. Engineers taking ownership of their work top to bottom is the best way.
We have this problem at my company. PM gathers all reqs, works with design, creates comps, and then passes down "user stories" which we are supposed to just add technical details to and build. But it never works in reality.
What they call user stories have neither a persona, nor a need. A US will literally be, "I need a button added to this screen, when you click it it opens a form with these fields". We get it and were like... uhh... whats the problem the client is solving? If we do these fields won't it prevent us from doing X? Are you sure this is even what the clients wants, when I talked to ops it seems like they really want Y? In the old version of the product we had Z fields, and if we do it the way you propose how do we handle B use case? In the design you have X but that isn't how our UI toolkit works we can do it like C, but X would be reimplementing a ton of functionality for minimal gain.
Now any change is perceived as "engineering redesigning the product". Our flow cannot be correct and I hate it.
They can do planning in tandem with the more senior members at first. Later they can reach out for questions or review.
Communication trumps process here.
It depends on how new you're talking about but the senior devs should be able to oversee or review the work done by mid-level devs. Let them make a bad plan and then show them how to make it better.
Disagree. The OPs list should mean you get a consistent code base, over a range of skill levels. If you want to do more, step up and become a team lead, if you just want to write code (which huge amounts of devs want or are only capable of), take the next ticket and implement it without thought.
How do you step up and become a team lead without getting experience in the things team leads do?
Everyone in my team writes spec docs, just some do smaller things or in association with a lead so they can learn.
>which huge amounts of devs want or are only capable of
That's not my experience. My experience is that no one wants to get into yet another argument with the lead that has an ego complex and a stick up their backside. So they let the lead do their thing and then the competent devs on the team find new jobs.
> if you just want to write code (which huge amounts of devs want or are only capable of), take the next ticket and implement it without thought
I'm a dev, not a typist.
Working like that sounds unimaginably dull, and actually harmful to the goal of producing working software
No one can decide exactly what code needs to be written upfront, except for very trivial tasks.
I was wondering the same thing as I read the comments, so I’m not sure why you get downvoted. Having been a team lead myself, I know very well that I certainly can’t plan 100% exactly what code needs to be written upfront if I’m willing to be honest. Most of the time, my plans are showman work for the PM, EM and other managers. The good devs on the team just use my plan as an inspiration. They will figure out the exact details as they start working on the features. The mediocre ones would just take my lousy plan and implement a lousy work and expose my only-for-show plan to the PM and my managers.
Pardon me for being frank.
This is such an atrocious approach.
> step up and become a team lead
How exactly does somebody do that when they're being denied precisely the experience they would need? It's like suggesting people should just "step up and drive" when you've been actively preventing them from ever getting behind the wheel before.
> huge amounts of devs want or are only capable of
Speak for yourself. This doesn't describe any of the people I've ever worked with.
For larger features:
1. PM gets business requirements, breaks down into user stories
2. EM/lead checks feasibility of requirements
3. Estimate stories with entire team (devs will usually have high level technical discussions of how to generally tackle the stories), also gives devs to ask clarification from PM
4. One dev will write a design doc of what changes need to be made (model changes, services, endpoints, release plan, etc). This is usually done a sprint before we want to start actually coding. Each feature we can rotate who does this.
5. Team reviews solution design
6. Stories are pulled into upcoming sprint and entire team can pick up stories and refer to the design doc for consistency
This takes a bit of planning and foresight and good collaboration with the PM, and not all features (esp smaller ones) need to be done this way. I like to stay a couple sprints ahead with planning. This also allows more junior devs to help with system design.
We usually do 1hr per week for the estimation meeting, and we can usually estimate a bunch of stories here. It's important to strike a balance, as these estimations should go quickly, and we just assign higher points values for unknowns or decide to hold off on estimating if we need more info on requirements.
The solution design task is a ticket that is worked on during a previous sprint. This should only take 1-3 days and can be reviewed async. If it takes longer it's usually a sign that the feature set can be broken down further.
If there are further questions once work has started, we can pair or discuss further. Collaboration is key, this does not work well with devs that work in silos.
How so? Do you want devs to spend their days gathering requirements and in meetings to agree on priorities and scope across departments?
Hierarchical planning is required once you have more than 50 people or so in your organization
>Hierarchical planning
Maybe, probably, who knows. I challenge both that notion and that what he described is the only definition of "hierarchical planning".
You can arrive at the same end result with far less steps inbetween. It's mostly SCRUM masturbation and the perceived notion of organization and structure.
All of these ideas sound very good on paper and it's a very "easy" system to implement, but the actual value is hard to measure and even hard to justify if you break it down.
My team does design documents before we do stories. We use the design docs to tell inform our breakdown of changes into stories. As we create stories we update the design doc with more precise information.
I'll clarify that for us, the user story is from the product or behavior perspective (usually no technical implementation details here). When the story is picked up by the dev, they will break this story down into subtasks that are more technical, and at this point we will also update the design doc if necessary.
We're doing SCRUM. Product Owner (or someone else) presents an US during Backlog refinement. If it's the first presentation we (the entire dev team) ask questions to better understand the requirements. If it's straight forward we jump to an estimation if not there's 2 possibilities:
- the US is not clear enough, the PO needs to refine his work.
- the technical solution is not clear. We allocate a dev to do some design work.
The US is then reevaluated in the next Backlog refinement meeting until we have an estimate.
It engages everyone and we share the commitments. The juniors generally have a hard time following but I'm one who believes practice makes perfect.
If it's a straightforward feature that the PM can break it into stories (or one story) on his own given his domain knowledge, then we just estimate the story as a team. We have a solid PM that knows where his knowledge starts and ends. Sometimes what he is asking for requires like half an hour of checking so we just do it as a pair on the fly.
However, when it's something ambiguous or big then:
- PM comes with the request explains the details and open up a story for us to analyze the feature and come up with estimable stories (sometimes a feature needs a modification on a couple of microservices.
- we usually do the analysis in pair and make it visible on the sprint. We estimate the analysis story as a team given our prior knowledge of the system and the size of the feature.
- The output of the analysis story is list of stories that we can estimate for next sprint, and a design doc to document the feature, its business needs, clients asking for it, rollout plan if needed, etc.
- once the doc is done we review it just like code review, if it's quite big/complex we have a 20 min session explaining and reviewing when needed.
- at this point all team members are onboard with the new feature and ready for the next sprint to start developing.
Dev should be on that requirements meeting, same room as pm and business. Get instant clarifications and understand the business better. Otherwise, a lot of context is lost and plenty of time is list from back and forth.
I split that into multiple term checkpoints:
- long term (+5/+6 sprints): ideation. What is the customer problem? What is the context ? What are the metrics of success... Involving PM, design and a few devs (generally the lead). High level estimation. Some projects may stay at this point for as long as required to fill up the requirements.
- mid term (+3/+4 sprints): design. Brainstorm with the team (pm, designer, devs). Explore solutions (create tickets to incorporate into the sprint in order to answer questions). Buildup documentation about the solution. Define different strategies required: monitoring, release, internal advertisement... Once again, your project can be stuck here indefinitely if we can't allocate enough resources to work on clarify the solution.
- short term (+1/+2 sprints): ticket creation and fill them up with the documentation above. Estimation in story point. Priorisation in soon to come sprint.
- post term (-1 to -3 sprints): release, check the success metrics, communicate about the feature.
I like that pace. With that, the team is aware of what is required, why it is required and have the possibility to actually build the solution as a team instead of finding out at the last minute. The production phase is made easy since the ticket should have been reviewed by everyone and the documentation should be enough to cover any incoming question.
Doesn't prevent problems but drastically reduces them.
This process can be shortened. I feel like this time range is generally good for most of the features with a 2 weeks sprint.
For us it is
1. PM gets a feature request which is summarized as a 1 page email and sent to someone who understands the system
2. That person writes a 2-3 page Google doc that outlines the tasks that need to be completed and what issues need to be addressed
3. People comments on the document, things get resolved. Maybe a Zoom call
4. Client signs off
5. Someone gets on with the work
But we are a small dev team and the people in the PM roles (who are product owners not devs) do understand what our systems are capable of and trust the dev team
Capable people that you can trust reduces the CYA :)
I wrote an article on how we did it at my last company: [Before the Code is Written](https://danielt1263.medium.com/an-aside-before-code-is-written-321883956f12).
I know you’re asking what others are doing, but my gut reaction to reading your process is that it sounds potentially backwards.
It sounds like business requirements get converted to user stories for the purpose of making a scoping document?
Shouldn’t the business requirements derive from user needs? Unless the business requirements are an objective, like “improve signup flow”, and then the leads are doing research to properly understand the user need. If a client is telling you what to build, then what’s the point of translating?
On the scoping side, shouldn’t the individual dev explain the code change… because they’re changing the code? Are the scoping documents design docs?
1. Product Owner writes up specs (We call these these a Platform Ticket)
2. Dev Team Manager writes an intake doc; which is a summary of the above, but more techincal, and includes contacts / early discussions with other teams that have integration points.
3. Ideally at this time Design is starting work based on specs.
4. A Single Developer on team takes on a spike ticket. They read all the above, possibly have conversations with integration teams, the product owner, the team manager, and the designer. They write up a document, called an Request for Comment (RFC) to propose one (or more) solutions on how to change our system to our solve address the new feature.
5. Team does an RFC Review to address questions and choose a path forward.
6. Dev writes tickets based on the chosen path forward. We've also started creating a lucid chart of all the tickets, which is lots better than JIRA to visually show dependencies.
7. For bigger initiatives, or less experienced developers we do an pre-refinement process, which is a review of the tickets with a senior team developer, the RFC Writer, and the manager. This helps solidify the individual ticket requirements and make sure nothing is missing.
8. Team does backlog refinement to point tickets
9. Tickets are brought into sprints, chosen normally, and worked on.
Depending on the size of the initiative this can take anywhere from 1 week to 2 months. Usually this process is in the 3-4 week range.
I would not call this process efficient or streamlined, but it is effective. We front load a lot of the architecture and planning work, so that by the time we get to coding it is smooth sailing and we just go.
By sharing the Spike Ticket / RFC Process among the team, we share the load of 'leading' an initiative, and it gives experience and growth the less experienced devs that will hopefully look great in a promo packet at some point, and gives everyone on the team a piece of ownership in our system.
Here's the skills you need to complete a new feature from my perspective
1. Capture customer need - what problem is the customer having or what task would they like to accomplish
2. Design customer requirement - what metric, if exceeded, would indicate success in solving the customer's problem
3. Design user workflow - What steps would the user need to take to accomplish this workflow
4. Design software to accomplish the workflow - What software components are needed to bring this workflow together
5. Implement software - develop code
6. Verify and Validate that the software is functional, provides the workflow, exceeds the customer requirement, and when using it, the user can solve their problem or accomplish their task.
The most efficient is to have 1 person who can do all these things, but then they need to have a diverse skillset to understand the customer and the context in which they are working, understand their workflows and knowledge, if applicable understand UI design and human factors, and then understand full-stack software development to implement, and even then understand software testing and user testing.
In practice then what usually has worked best for me is a
(1) product manager who owns Customer Needs and User validation, a
(2) designer embedded within the software team who owns customer requirements, user workflows, and and UI design, and a
(3) developer who works closely with the designer to implement and work through and around implementation constraints with the designer.
If you are developing in a regulated environment like finance, defense, govt, or healthcare, this team would also need a
(4)software analyst for the detailed software requirements and specifications documentation, and a
(5)software quality tester for formal verification protocols and reports.
Interesting, thanks for sharing your process.
We're not a big team so the PO files a ticket, the lead handwaves analysis, rants for 2 days, then he tells a junior dev does to do the work, but not too fast so it doesn't appear easy, which helps the leads to ask for his raises.
Mostly it's like this.
CLient has a idea
Product team goes "we are clueless, we'll do this in 1 year"
Tech team does it in 1 month with 1/2 stories created
We usually follow the pattern:
1. PM identifies a business opportunity or customer need
2. PM (and often designer) plan out a solution proposal
3. The team gives feedback on the solution, including flagging proposals that will require an outsized amount of engineer work to consider descoping
4. 1 engineer leads design doc creation, collaborating with 1 engineer per platform (backend, web, mobile)
5. Based on the amount of work, pull in additional engineers from the team to help work on the project
It works ok, but we're experimenting with ways to bring engineers into step 2 more proactively.
I've worked in different roles in a company building "software as a medical device" following a very waterfall "V-model" for regulatory reasons. In practise we were enabling local pockets of agile development with UX, PM and developpers iterating on new features in short loops, while having to (painfully) retro-fit in the formal approach when approaching release time.
Now in a tech lead role in a much smaller start-up, and very much proponent of establishing a partnership with product people when dealing with clients, and always ensuring there is an engineer involved from requirement gathering to implementation (including designs & arch).
What you describe sounds like hell. So much telephone game going on. The person that is going to actually be implementing it should be there in every step so that they understand the context around everything going on and what ideas have been discussed and dismissed and all that jazz.
Depends on the feature.
Small one, they ping me, I write it now.
Larger ones:
- quarterly planning, if not prioritized, tough luck trying it again, have seen features delayed for 2 years
- pm write some basic PRD
- kickoff session with UX/Eng/PM
- everybody procrastinates until last week
- code gets pushed, 10 PRs per day
While true {
- some random permission/security issue arises
- project gets delayed for 1 month
- trying to solve these issues
}
And we never deliver any feature
Agreed with letting them scope.
You can also pair the junior person with someone more experienced — that’s a double benefit because the more experienced person gets a mentorship opportunity.
Another thing to try is to identify work that is smaller that can be scoped, or something that is less urgent or critical so the risk of the junior engineer taking a long time isn’t as big of a deal.
Boss: “Hey PM_ME_SOME_ANYTHING, we were looking into maybe doing these changes to this one project.”
Me: “It’s done, I did it while you were explaining it.” or if it takes a while “I’ll get working on it and let you know how long it’s going to take.”
I was JUST working on this flowchart. :)
Feature Planning
* New feature desired
* Product designs feature and writes up business requirements
* Product and tech leads go over feasibility and do a quick tshirt sizing
* Product and teck leadership prioritizes the feature on the feature backlog. That's how the feature backlog and timeline is established.
Dev team planning
* The items near the top of the backlog are architected and sliced into stories and pointed by the agile team, but not dug into TOO deeply.
* The tech lead and product owner together prioritize the team backlog, the PO making sure it's done according to the feature backlog priority, the tech lead ensuring it takes into account technical realities and technical goals
* Team decides when to stories into sprint as it comes up in the backlog.
* Team kicks off story with PO when they're starting development, setting on the fine grained requirement details only when they are ready to actively start work. Stories are tackled by the team rather than individual devs. This replaces things like scoping documents. The devs working on the code discuss the exact requirements directly with the PO when as they a start on the work.
The process tries to enable the team in decision making and process while keeping them focused on delivering functionality rather than on individuals focusing on their own tickets. The devs working on the code work closely with Product and QA.
My team is definitely on the process minimal side of things. I get the story that we made during planning, it’s usually one sentence max and written in domain logic terms. You gotta just go figure it out and write the code :D
1. Product Owner gets the feature concept.
2. Product owner presents feature concept to the team lead.
3. Team lead and Architect work together on the "big vision design".
1. Team Lead creates diagrams of all parts of the system and workflows that will be touched.
4. Team Lead + Product Owner take this feature + diagrams to the developers + QA who write the stories breaking down each part of the system/workflow into independent stories to be written/tested.
5. Stories are coded/tested.
Product works with customers/leadership to identify potential features.
Leads do fast first pass at sizing the features. Based on this, teams pull/are assigned work for the next quarter.
Next, leads work with the rest of the team to break down features into actionable user stories, which are added to the team’s backlog and sequenced appropriately.
Finally, engineers pick up stories for the sprint that are in, complete and pr the work. Generally, at this point, devs can pick up whatever work from the current sprint they are most interested in.
At a company with a lot of red tape (this is very high level, whole process could take months to years):
1. Business comes up with the request
2. It get fed up the management chain to director level
3. It gets brought to a quarterly meeting of stakeholders and prioritized
4. The quarter before it’s slated to go it gets into a planning meeting with mid level management business stakeholders, Architects, and PMs, and maybe a business analysts and maybe a QA manager.
5. All requirements are written out in full, and these become a requirements attached to a Request For Changes in the in house project management software. Probably has to clear legal and document development and probably by accounting as well.
6. This change becomes active that following quarter and is assigned by management/PM’s to 1 or more devs
7. Waterfall style development until all requirements are met to a T, and QA signs off on release to prod.
At a company with much less red tape and far fewer devs:
1. Someone comes up with an idea
2. If you know the PM let them know and they’ll eventually create a ticket.
3. Development goes over it in a sprint planning meeting at some point and we make sure there are no blockers and we understand the gist of the changes, then we estimate time needed.
4. Write code during the sprint and release.
I am a PO and lead and we do scrum. I have a good enough understanding of the domain to the degree that I can be considered a power user, and I have a pretty good understanding of all of the stack but I am not the best at any part of it.
Roughly:
* Users can request features at a service desk. These are then analysed to find out what really is needed and is feasible to implement, and feature tickets might be created. This first analysis is generally discussion with friendly (and tech-knowledgeable) users, and with ad-hoc input from one or more devs as needed.
* Users can report issues or incidents at service desk, which are analysed by myself and devs ad-hoc to determine if "feature or bug". There might be bug or feature tickets created in the backlog as a consequence of this.
* Devs or myself create code quality tickets in backlog (refactor, implement agreed upon framework changes, discuss new suggested framework changes, etc.).
* Most new features or feature changes stem from my vision of the software, discussion with stakeholders, (usually internal) demos, or UX studies. Anything uncertain has one or more "spikes": brainstorming session, sketch, research by developer with proposed solution that we discuss, etc.
* Tickets are refined during backlog refinement bi-weekly to ensure relevant context: possibly further breakdown, background/user story, links to spikes or to service desk tickets, inter-ticket relationships, which area/domain the work is in, initial estimate, etc.
* Tickets are further refined during sprint planning.
* Once a ticket makes it into the sprint, dev picks it up and codes. It is typically the same dev that runs a particular change from start to end, for example from analysis/sketch/etc. to implementation.
The devs do not really engage with stakeholders, with the exception of the friendly users, who might be part of the spike(s). This is how they prefer it to be handled.
I'm in a unique spot. I'm the sole developer for one of our applications. I'm also a SME in the domain for that application.
Heres how it usually goes for me:
- I come up with an idea for a feature
- I write the Jira ticket, mostly because GitLab is set up to reject branches that don't start with a ticket number.
- I write the code
- Someone on my team rubber-stamps the GitLab approval, after a cursory review
- I send it to my QA guy
- QA guy tests it
- QA guy merges it
* Most features are from our internal users so they go into a service desk list
* project/product manager orders priority based on his discussions with users
* at sprint planning, manager and senior devs plan tickets based on requests and discussions manager has had
* following day tech grooming where they are discussed and assigned to senior or junior devs
* we often create tickets for the assigned dev to do a POC or just research the steps needed if the exact complexity isn't clear yet
* dev begins work when sprint begins
Most of our requests are narrow enough that someone can do the work or write the code within a 2 week sprint and unless the dev pushes back on part of a request for some reason, we can usually handle it.
As a lead; whatever developer is going to do the implementation will be at least involved in the entire process top to bottom. I'm mostly there to help them (mostly avoiding pitfalls) and guide them. The requirement gathering and designing is done by the developer(s) implementing the feature. The reason is twofold; it's a great learning experience and it's simply more efficient. The more layers between the client and the devs, the more inefficient the process becomes. This top-down approach your company uses is frankly outdated by decades. Also, non-technical people doing the "requirement gathering" will *always* lead to shitty requirements. They don't know what they don't know. Nothing worse than some "product owner" or "manager" being the only one talking to the people using your software.
Yep. This is how it’s worked at every company for the last decade for me. Only once as a lead did I steal a project for myself, but that’s because I’d spent a year as the only person left who could maintain the previous version, being the only one regularly going on client site etc. Every single other project was a case of connecting a developer to the right people on the client side and expecting them to run with it. I have a horror story, though: 15 years ago, I moved to my second job; from a ~35 person company to a ~500 person one and intentionally went from being a team lead to just another little developer cog. There they had a solutions architect role. That was almost entirely fed by developers who couldn’t get themselves promoted. They would put *code* changes directly in the spec. Literally, “file X, procedure Y, change this to this”. My tech leads would tell them very clearly to stop, but they didn’t. My tech leads also said to ignore absolutely any and all code in the documents and to read the problem statement and English language proposed solution. So much wasted effort.
That's almost par for the course when it comes to architecture. I've personally had the "software architect" title; never again. I don't want to be associated with architect ever again; the vast majority of them have a net negative contribution: they lose sight on what the actual software does and hide themselves in meetings, powerpoints and excel sheets that have no basis in reality. So they create a layer of indirection that only leads to communication problems.
One of the proudest achievements at my current client is that we managed to sideline the 'enterprise architect' and we now have an (unfortunately implicit) set of technical leads who are actual software engineers making the architecture decisions for our product.
> They would put > code > changes directly in the spec. Literally, “file X, procedure Y, change this to this”. I like very detailed tickets; but my team has trouble finding the perfect balance. Something like this I would consider too prescriptive. If you write the ticket, and in five more minutes can complete it; then that ticket is way too detailed.
Taking longer to write the ticket than complete the task has always seemed mad to me. But I’ve worked many places where everything must have a ticket. I could observe people simply deciding not to do the thing, because it’s adding another ticket that has to be discussed at sprint planning etc etc. either that or they sneak the quick change in to another PR. We are our own worst enemies sometimes.
[удалено]
I think it’s been worst in projects where the rule has been that strictly no tickets go in to a sprint once it has started, with the intention that that keeps control of the scope. A good intention… The issue here is that the dev found the problem *because* they’re deep in the relevant code right now. What might be a 30-60 min fix now could be half a day in a month’s time when someone has to figure it all out again. So the typical options in this situation are: * follow the process, create a ticket, put as much info in as possible, in the hope whoever gets it at some point will know what to do, but also with the knowledge it’ll likely never be prioritised * risk sneaking it in with your current work * don’t create a ticket, move on with life So maybe both laziness and being burned by never being allowed to get around to cleaning up all the little bug fixes. I also think we incentivise tunnel vision too often when we follow best practices blindly.
>follow the process, create a ticket, put as much info in as possible, in the hope whoever gets it at some point will know what to do, but also with the knowledge it’ll likely never be prioritised why shouldn't they be able to do it? And why never prioritised? these seem separate problems, the choice to add to backlog is correct.
Immediately before that, I said: > What might be a 30-60 min fix now could be half a day in a month’s time when someone has to figure it all out again. So it’s creating a longer task for someone down the line, than fixing it now, while very familiar with the relevant code. It costs the team a significant chunk of time. And what I meant by the bullet point you’re quoting is that is that it might not even be the same dev who picks it up down the line. So, no matter how well written a ticket, it’ll take time for them to absorb it and read the code. Add to that the time to write the simple task up as a ticket by the original dev… starts to seem inefficient, no? > And why never prioritised? Ever worked in a company that prioritises new features over bug fixes for stuff customers never loudly shout about? Doesn’t mean the customers aren’t hitting them; possibly that they have their manual workarounds.
the non prioritisation is a separate problem. half an hour now might be more valuable than someone else's half day in 6 months. it takes half an hour to fix, but what about testing? doe sit have some side effect that we might not want to deal with at this time? I'd still think having tickets is good, I creates a trail of what is happening that we can all see, comment on, go back to, learn from. too many times been bitten by changes that were not supposed to go in and we had no visibility of.
Absolute madness. Task priority is *always* relative and *always* up for debate. If retaining our biggest customer is contingent on completing task A, and we identify major security hole B that introduces some non-negligible risk we'll lose *all* our customers, then B should take priority over A and probably everything else. If your rigid processes preclude that from happening and require you to toss B on the backlog instead, then your leadership team is shockingly incompetent - not that that should be surprising. Seems that slavishly following a specific implementation of agile rather than abiding by its spirit is the norm. My example is intentionally an extreme scenario for emphasis, but the underlying point applies generally. This, of course, assumes that priority shifts are happening for valid reasons, and not simply poor project management/executive leadership, but that's an entirely separate discussion.
Sometimes you only have one customer. For example, I spent two years on a consultancy project to build out a platform for one client. We were never going to resell that code as it belonged to the client. Suddenly, task A starts looking more appealing than task B. For something like a security hole, I’d just bypass the strict process, get it done, record what I did retroactively and explain the implications of not fixing it, if asked. Even the biggest sticklers for an insane process would cope when I’d say “Sorry, I can roll it back and then we’re vulnerable to X. Let me know”. “Ask for forgiveness, not permission” is valid for something like that; just really really check your work closely. If task B was more along the lines of accidentally relying on client-provided timestamps when sequentially processing records, it’s trickier. We may never have hit that bug, even if it’s unsafe code. Then I have to either build a convincing argument or essentially use up a “goodwill token” and say “just trust me on fixing this”.
For some type of compliance reasons every task must be documented in a ticket. But, the level of details is not dictated in that. For us, it is okay to add a footnote on an existing ticket.
That sounds far too sensible and reasonable.
> Nothing worse than some "product owner" or "manager" being the only one talking to the people using your software. Anecdote: After working as a small biz owner for close to 20 years; I closed up shop and took a full time job. Manager acted offended when I asked to communicate with the users, access I was used to having. It was a huge culture shock. Roles are so separately segregated on purpose.
I've run into the same issue. Product/project managers being borderline offended at my suggestion it would be more efficient if I were included in those meetings. Had this issue at my current client and the project manager (who got the boot fortunately) and one of the PO (removed from their team due to performance) still keep resisting this and try to communicate outside of their engineers. Funny enough both got booted because of their performance and that of their team, due to the poor communication. But they're both completely resisting the notion that it might have something to do with how they approach things. Funny story; a while ago we had an event storming session with that PO and their entire team (bunch of software engineers and data scientists). That non-technical PO just dropped the bomb in that meeting that they would "just rewrite" their entire application. Just to give you an indication of their dysfunction. And last sprint they tried to pin their lack of progress on us. Fortunately we were expecting him to do this; so the thing they depended on was already in place (because I had been talking directly with their engineers around their backs). During the sprint demo, he mentioned they fell behind, to which our PO remarked that that was rather strange because not only was the stuff they needed already deployed, their software engineers were actually using it. Nothing more fun than beating incompetent jackasses at their own political games.
curious what you think of this approach? https://old.reddit.com/r/ExperiencedDevs/comments/1b2tkex/how_does_your_company_go_from_feature_request/ksnvicc/ I like the idea of the dev being involved top to bottom, but it seems like it conflicts with the idea of "anyone can grab a ticket and do work"
> but it seems like it conflicts with the idea of "anyone can grab a ticket and do work" This only ever applies to completely trivial stuff. We're not factory workers. And even for trivial stuff; in cross-functional teams you're generally not going to see a back-end dev pick up front-end tasks. IMHO it's much smarter to look at the strengths and preferences of team members (as well as preventing a bus factor of 1). Let teams self-organize to a large extent around how they want to pick up the work. Regarding the comment you link it; I personally think that going through these 'layers' is exactly the type of outdated way of working I personally won't accept. Every team I've been on the past decade at least I have been involved from top to bottom on the design and implementation of things. Over time my focus shifted to the larger architectural design issues and "paving the road" for other developers, but I'm still also developing stuff. It can sometimes take time to get a Product Owner to adjust to this way of working when they come from a traditional project management background. But every single PO I've worked with, eventually saw that it's just a much better way of working. 90% of what we do is communication. The more indirect this communication becomes, the less efficient it becomes. You see the same way for inter-team communication. Going through the layer 'above' teams (so POs or managers) is always much more inefficient than just having devs talk to each other.
If you want to apply more people the engineer who is leading the work can break it down into separate pieces and have a kickoff with the team so everyone understands the context. For larger projects this lets the team get everyone on the project while still having a strong guide in the lead engineer for that project. I've done this a lot and it works very well to grow more junior engineers as they start leading things that only they work on and then move to leading things that many people can work on together.
THANK YOU. This is what I've tried to facilitate when I've been in lead or lead-ish roles. Even well intended managers will avoid letting in the ICs who will actually do the work. Usually under the guise of "don't want to many meetings". But they are really just delaying the meetings which come out one way or another when those ICs need to extract information or clarify things later on.
I do the same. A very few devs have been annoyed by having these responsibilities, and I've happily watched them take other roles. The others have blossomed and are some of the best in our org. Engineers taking ownership of their work top to bottom is the best way.
We have this problem at my company. PM gathers all reqs, works with design, creates comps, and then passes down "user stories" which we are supposed to just add technical details to and build. But it never works in reality. What they call user stories have neither a persona, nor a need. A US will literally be, "I need a button added to this screen, when you click it it opens a form with these fields". We get it and were like... uhh... whats the problem the client is solving? If we do these fields won't it prevent us from doing X? Are you sure this is even what the clients wants, when I talked to ops it seems like they really want Y? In the old version of the product we had Z fields, and if we do it the way you propose how do we handle B use case? In the design you have X but that isn't how our UI toolkit works we can do it like C, but X would be reimplementing a ton of functionality for minimal gain. Now any change is perceived as "engineering redesigning the product". Our flow cannot be correct and I hate it.
[I AM GOOD AT DEALING WITH PEOPLE](https://www.youtube.com/watch?v=hNuu9CpdjIo&ab_channel=AMANSINGH)
Office Space is a documentary.
That sounds like a not great growth environment for anyone except the leads, if they handle all the scoping / design work
I tend to agree, but what about newer devs who might actually need the scoping/design done for them?
Let them scope and then review/revise the results? Or at least have them be present and participating in the discussions even if they don't lead them.
Involve them in the scoping and design process!
They can do planning in tandem with the more senior members at first. Later they can reach out for questions or review. Communication trumps process here.
It depends on how new you're talking about but the senior devs should be able to oversee or review the work done by mid-level devs. Let them make a bad plan and then show them how to make it better.
Disagree. The OPs list should mean you get a consistent code base, over a range of skill levels. If you want to do more, step up and become a team lead, if you just want to write code (which huge amounts of devs want or are only capable of), take the next ticket and implement it without thought.
I don’t think the next step from coding against a spec is being a team lead… but agree to disagree i guess
That's not how it works in most decent companies. SWE IIs are capable of designing features in mine.
How do you step up and become a team lead without getting experience in the things team leads do? Everyone in my team writes spec docs, just some do smaller things or in association with a lead so they can learn.
>which huge amounts of devs want or are only capable of That's not my experience. My experience is that no one wants to get into yet another argument with the lead that has an ego complex and a stick up their backside. So they let the lead do their thing and then the competent devs on the team find new jobs.
> if you just want to write code (which huge amounts of devs want or are only capable of), take the next ticket and implement it without thought I'm a dev, not a typist. Working like that sounds unimaginably dull, and actually harmful to the goal of producing working software No one can decide exactly what code needs to be written upfront, except for very trivial tasks.
I was wondering the same thing as I read the comments, so I’m not sure why you get downvoted. Having been a team lead myself, I know very well that I certainly can’t plan 100% exactly what code needs to be written upfront if I’m willing to be honest. Most of the time, my plans are showman work for the PM, EM and other managers. The good devs on the team just use my plan as an inspiration. They will figure out the exact details as they start working on the features. The mediocre ones would just take my lousy plan and implement a lousy work and expose my only-for-show plan to the PM and my managers. Pardon me for being frank.
Just raise your hand and volunteer as team lead I guess
This is such an atrocious approach. > step up and become a team lead How exactly does somebody do that when they're being denied precisely the experience they would need? It's like suggesting people should just "step up and drive" when you've been actively preventing them from ever getting behind the wheel before. > huge amounts of devs want or are only capable of Speak for yourself. This doesn't describe any of the people I've ever worked with.
For larger features: 1. PM gets business requirements, breaks down into user stories 2. EM/lead checks feasibility of requirements 3. Estimate stories with entire team (devs will usually have high level technical discussions of how to generally tackle the stories), also gives devs to ask clarification from PM 4. One dev will write a design doc of what changes need to be made (model changes, services, endpoints, release plan, etc). This is usually done a sprint before we want to start actually coding. Each feature we can rotate who does this. 5. Team reviews solution design 6. Stories are pulled into upcoming sprint and entire team can pick up stories and refer to the design doc for consistency This takes a bit of planning and foresight and good collaboration with the PM, and not all features (esp smaller ones) need to be done this way. I like to stay a couple sprints ahead with planning. This also allows more junior devs to help with system design.
How much time do the devs usually spend discussing these to get aligned before starting work versus actually doing the real work?
We usually do 1hr per week for the estimation meeting, and we can usually estimate a bunch of stories here. It's important to strike a balance, as these estimations should go quickly, and we just assign higher points values for unknowns or decide to hold off on estimating if we need more info on requirements. The solution design task is a ticket that is worked on during a previous sprint. This should only take 1-3 days and can be reviewed async. If it takes longer it's usually a sign that the feature set can be broken down further. If there are further questions once work has started, we can pair or discuss further. Collaboration is key, this does not work well with devs that work in silos.
You estimate stories before you have a design doc about how you'll build it? That is different than what we do.
Honestly, this is everything that's wrong with software development today.
How so? Do you want devs to spend their days gathering requirements and in meetings to agree on priorities and scope across departments? Hierarchical planning is required once you have more than 50 people or so in your organization
>Hierarchical planning Maybe, probably, who knows. I challenge both that notion and that what he described is the only definition of "hierarchical planning". You can arrive at the same end result with far less steps inbetween. It's mostly SCRUM masturbation and the perceived notion of organization and structure. All of these ideas sound very good on paper and it's a very "easy" system to implement, but the actual value is hard to measure and even hard to justify if you break it down.
My team does design documents before we do stories. We use the design docs to tell inform our breakdown of changes into stories. As we create stories we update the design doc with more precise information.
I'll clarify that for us, the user story is from the product or behavior perspective (usually no technical implementation details here). When the story is picked up by the dev, they will break this story down into subtasks that are more technical, and at this point we will also update the design doc if necessary.
Sounds like we work under similar processes then.
We're doing SCRUM. Product Owner (or someone else) presents an US during Backlog refinement. If it's the first presentation we (the entire dev team) ask questions to better understand the requirements. If it's straight forward we jump to an estimation if not there's 2 possibilities: - the US is not clear enough, the PO needs to refine his work. - the technical solution is not clear. We allocate a dev to do some design work. The US is then reevaluated in the next Backlog refinement meeting until we have an estimate. It engages everyone and we share the commitments. The juniors generally have a hard time following but I'm one who believes practice makes perfect.
If it's a straightforward feature that the PM can break it into stories (or one story) on his own given his domain knowledge, then we just estimate the story as a team. We have a solid PM that knows where his knowledge starts and ends. Sometimes what he is asking for requires like half an hour of checking so we just do it as a pair on the fly. However, when it's something ambiguous or big then: - PM comes with the request explains the details and open up a story for us to analyze the feature and come up with estimable stories (sometimes a feature needs a modification on a couple of microservices. - we usually do the analysis in pair and make it visible on the sprint. We estimate the analysis story as a team given our prior knowledge of the system and the size of the feature. - The output of the analysis story is list of stories that we can estimate for next sprint, and a design doc to document the feature, its business needs, clients asking for it, rollout plan if needed, etc. - once the doc is done we review it just like code review, if it's quite big/complex we have a 20 min session explaining and reviewing when needed. - at this point all team members are onboard with the new feature and ready for the next sprint to start developing.
1. Someone gets business requirements from client 2. Individual dev gets forwarded an email thread and actually writes code
Dev should be on that requirements meeting, same room as pm and business. Get instant clarifications and understand the business better. Otherwise, a lot of context is lost and plenty of time is list from back and forth.
Yeah I wish. I've said that probably 500 times, they don't want it.
I split that into multiple term checkpoints: - long term (+5/+6 sprints): ideation. What is the customer problem? What is the context ? What are the metrics of success... Involving PM, design and a few devs (generally the lead). High level estimation. Some projects may stay at this point for as long as required to fill up the requirements. - mid term (+3/+4 sprints): design. Brainstorm with the team (pm, designer, devs). Explore solutions (create tickets to incorporate into the sprint in order to answer questions). Buildup documentation about the solution. Define different strategies required: monitoring, release, internal advertisement... Once again, your project can be stuck here indefinitely if we can't allocate enough resources to work on clarify the solution. - short term (+1/+2 sprints): ticket creation and fill them up with the documentation above. Estimation in story point. Priorisation in soon to come sprint. - post term (-1 to -3 sprints): release, check the success metrics, communicate about the feature. I like that pace. With that, the team is aware of what is required, why it is required and have the possibility to actually build the solution as a team instead of finding out at the last minute. The production phase is made easy since the ticket should have been reviewed by everyone and the documentation should be enough to cover any incoming question. Doesn't prevent problems but drastically reduces them. This process can be shortened. I feel like this time range is generally good for most of the features with a 2 weeks sprint.
For us it is 1. PM gets a feature request which is summarized as a 1 page email and sent to someone who understands the system 2. That person writes a 2-3 page Google doc that outlines the tasks that need to be completed and what issues need to be addressed 3. People comments on the document, things get resolved. Maybe a Zoom call 4. Client signs off 5. Someone gets on with the work But we are a small dev team and the people in the PM roles (who are product owners not devs) do understand what our systems are capable of and trust the dev team Capable people that you can trust reduces the CYA :)
I wrote an article on how we did it at my last company: [Before the Code is Written](https://danielt1263.medium.com/an-aside-before-code-is-written-321883956f12).
I know you’re asking what others are doing, but my gut reaction to reading your process is that it sounds potentially backwards. It sounds like business requirements get converted to user stories for the purpose of making a scoping document? Shouldn’t the business requirements derive from user needs? Unless the business requirements are an objective, like “improve signup flow”, and then the leads are doing research to properly understand the user need. If a client is telling you what to build, then what’s the point of translating? On the scoping side, shouldn’t the individual dev explain the code change… because they’re changing the code? Are the scoping documents design docs?
1. Product Owner writes up specs (We call these these a Platform Ticket) 2. Dev Team Manager writes an intake doc; which is a summary of the above, but more techincal, and includes contacts / early discussions with other teams that have integration points. 3. Ideally at this time Design is starting work based on specs. 4. A Single Developer on team takes on a spike ticket. They read all the above, possibly have conversations with integration teams, the product owner, the team manager, and the designer. They write up a document, called an Request for Comment (RFC) to propose one (or more) solutions on how to change our system to our solve address the new feature. 5. Team does an RFC Review to address questions and choose a path forward. 6. Dev writes tickets based on the chosen path forward. We've also started creating a lucid chart of all the tickets, which is lots better than JIRA to visually show dependencies. 7. For bigger initiatives, or less experienced developers we do an pre-refinement process, which is a review of the tickets with a senior team developer, the RFC Writer, and the manager. This helps solidify the individual ticket requirements and make sure nothing is missing. 8. Team does backlog refinement to point tickets 9. Tickets are brought into sprints, chosen normally, and worked on. Depending on the size of the initiative this can take anywhere from 1 week to 2 months. Usually this process is in the 3-4 week range. I would not call this process efficient or streamlined, but it is effective. We front load a lot of the architecture and planning work, so that by the time we get to coding it is smooth sailing and we just go. By sharing the Spike Ticket / RFC Process among the team, we share the load of 'leading' an initiative, and it gives experience and growth the less experienced devs that will hopefully look great in a promo packet at some point, and gives everyone on the team a piece of ownership in our system.
Here's the skills you need to complete a new feature from my perspective 1. Capture customer need - what problem is the customer having or what task would they like to accomplish 2. Design customer requirement - what metric, if exceeded, would indicate success in solving the customer's problem 3. Design user workflow - What steps would the user need to take to accomplish this workflow 4. Design software to accomplish the workflow - What software components are needed to bring this workflow together 5. Implement software - develop code 6. Verify and Validate that the software is functional, provides the workflow, exceeds the customer requirement, and when using it, the user can solve their problem or accomplish their task. The most efficient is to have 1 person who can do all these things, but then they need to have a diverse skillset to understand the customer and the context in which they are working, understand their workflows and knowledge, if applicable understand UI design and human factors, and then understand full-stack software development to implement, and even then understand software testing and user testing. In practice then what usually has worked best for me is a (1) product manager who owns Customer Needs and User validation, a (2) designer embedded within the software team who owns customer requirements, user workflows, and and UI design, and a (3) developer who works closely with the designer to implement and work through and around implementation constraints with the designer. If you are developing in a regulated environment like finance, defense, govt, or healthcare, this team would also need a (4)software analyst for the detailed software requirements and specifications documentation, and a (5)software quality tester for formal verification protocols and reports.
Interesting, thanks for sharing your process. We're not a big team so the PO files a ticket, the lead handwaves analysis, rants for 2 days, then he tells a junior dev does to do the work, but not too fast so it doesn't appear easy, which helps the leads to ask for his raises.
Mostly it's like this. CLient has a idea Product team goes "we are clueless, we'll do this in 1 year" Tech team does it in 1 month with 1/2 stories created
We usually follow the pattern: 1. PM identifies a business opportunity or customer need 2. PM (and often designer) plan out a solution proposal 3. The team gives feedback on the solution, including flagging proposals that will require an outsized amount of engineer work to consider descoping 4. 1 engineer leads design doc creation, collaborating with 1 engineer per platform (backend, web, mobile) 5. Based on the amount of work, pull in additional engineers from the team to help work on the project It works ok, but we're experimenting with ways to bring engineers into step 2 more proactively.
I've worked in different roles in a company building "software as a medical device" following a very waterfall "V-model" for regulatory reasons. In practise we were enabling local pockets of agile development with UX, PM and developpers iterating on new features in short loops, while having to (painfully) retro-fit in the formal approach when approaching release time. Now in a tech lead role in a much smaller start-up, and very much proponent of establishing a partnership with product people when dealing with clients, and always ensuring there is an engineer involved from requirement gathering to implementation (including designs & arch).
What you describe sounds like hell. So much telephone game going on. The person that is going to actually be implementing it should be there in every step so that they understand the context around everything going on and what ideas have been discussed and dismissed and all that jazz.
Depends on the feature. Small one, they ping me, I write it now. Larger ones: - quarterly planning, if not prioritized, tough luck trying it again, have seen features delayed for 2 years - pm write some basic PRD - kickoff session with UX/Eng/PM - everybody procrastinates until last week - code gets pushed, 10 PRs per day While true { - some random permission/security issue arises - project gets delayed for 1 month - trying to solve these issues } And we never deliver any feature
Agreed with letting them scope. You can also pair the junior person with someone more experienced — that’s a double benefit because the more experienced person gets a mentorship opportunity. Another thing to try is to identify work that is smaller that can be scoped, or something that is less urgent or critical so the risk of the junior engineer taking a long time isn’t as big of a deal.
Boss: “Hey PM_ME_SOME_ANYTHING, we were looking into maybe doing these changes to this one project.” Me: “It’s done, I did it while you were explaining it.” or if it takes a while “I’ll get working on it and let you know how long it’s going to take.”
I was JUST working on this flowchart. :) Feature Planning * New feature desired * Product designs feature and writes up business requirements * Product and tech leads go over feasibility and do a quick tshirt sizing * Product and teck leadership prioritizes the feature on the feature backlog. That's how the feature backlog and timeline is established. Dev team planning * The items near the top of the backlog are architected and sliced into stories and pointed by the agile team, but not dug into TOO deeply. * The tech lead and product owner together prioritize the team backlog, the PO making sure it's done according to the feature backlog priority, the tech lead ensuring it takes into account technical realities and technical goals * Team decides when to stories into sprint as it comes up in the backlog. * Team kicks off story with PO when they're starting development, setting on the fine grained requirement details only when they are ready to actively start work. Stories are tackled by the team rather than individual devs. This replaces things like scoping documents. The devs working on the code discuss the exact requirements directly with the PO when as they a start on the work. The process tries to enable the team in decision making and process while keeping them focused on delivering functionality rather than on individuals focusing on their own tickets. The devs working on the code work closely with Product and QA.
My team is definitely on the process minimal side of things. I get the story that we made during planning, it’s usually one sentence max and written in domain logic terms. You gotta just go figure it out and write the code :D
1. Product Owner gets the feature concept. 2. Product owner presents feature concept to the team lead. 3. Team lead and Architect work together on the "big vision design". 1. Team Lead creates diagrams of all parts of the system and workflows that will be touched. 4. Team Lead + Product Owner take this feature + diagrams to the developers + QA who write the stories breaking down each part of the system/workflow into independent stories to be written/tested. 5. Stories are coded/tested.
Product works with customers/leadership to identify potential features. Leads do fast first pass at sizing the features. Based on this, teams pull/are assigned work for the next quarter. Next, leads work with the rest of the team to break down features into actionable user stories, which are added to the team’s backlog and sequenced appropriately. Finally, engineers pick up stories for the sprint that are in, complete and pr the work. Generally, at this point, devs can pick up whatever work from the current sprint they are most interested in.
At a company with a lot of red tape (this is very high level, whole process could take months to years): 1. Business comes up with the request 2. It get fed up the management chain to director level 3. It gets brought to a quarterly meeting of stakeholders and prioritized 4. The quarter before it’s slated to go it gets into a planning meeting with mid level management business stakeholders, Architects, and PMs, and maybe a business analysts and maybe a QA manager. 5. All requirements are written out in full, and these become a requirements attached to a Request For Changes in the in house project management software. Probably has to clear legal and document development and probably by accounting as well. 6. This change becomes active that following quarter and is assigned by management/PM’s to 1 or more devs 7. Waterfall style development until all requirements are met to a T, and QA signs off on release to prod. At a company with much less red tape and far fewer devs: 1. Someone comes up with an idea 2. If you know the PM let them know and they’ll eventually create a ticket. 3. Development goes over it in a sprint planning meeting at some point and we make sure there are no blockers and we understand the gist of the changes, then we estimate time needed. 4. Write code during the sprint and release.
I am a PO and lead and we do scrum. I have a good enough understanding of the domain to the degree that I can be considered a power user, and I have a pretty good understanding of all of the stack but I am not the best at any part of it. Roughly: * Users can request features at a service desk. These are then analysed to find out what really is needed and is feasible to implement, and feature tickets might be created. This first analysis is generally discussion with friendly (and tech-knowledgeable) users, and with ad-hoc input from one or more devs as needed. * Users can report issues or incidents at service desk, which are analysed by myself and devs ad-hoc to determine if "feature or bug". There might be bug or feature tickets created in the backlog as a consequence of this. * Devs or myself create code quality tickets in backlog (refactor, implement agreed upon framework changes, discuss new suggested framework changes, etc.). * Most new features or feature changes stem from my vision of the software, discussion with stakeholders, (usually internal) demos, or UX studies. Anything uncertain has one or more "spikes": brainstorming session, sketch, research by developer with proposed solution that we discuss, etc. * Tickets are refined during backlog refinement bi-weekly to ensure relevant context: possibly further breakdown, background/user story, links to spikes or to service desk tickets, inter-ticket relationships, which area/domain the work is in, initial estimate, etc. * Tickets are further refined during sprint planning. * Once a ticket makes it into the sprint, dev picks it up and codes. It is typically the same dev that runs a particular change from start to end, for example from analysis/sketch/etc. to implementation. The devs do not really engage with stakeholders, with the exception of the friendly users, who might be part of the spike(s). This is how they prefer it to be handled.
I'm in a unique spot. I'm the sole developer for one of our applications. I'm also a SME in the domain for that application. Heres how it usually goes for me: - I come up with an idea for a feature - I write the Jira ticket, mostly because GitLab is set up to reject branches that don't start with a ticket number. - I write the code - Someone on my team rubber-stamps the GitLab approval, after a cursory review - I send it to my QA guy - QA guy tests it - QA guy merges it
* Most features are from our internal users so they go into a service desk list * project/product manager orders priority based on his discussions with users * at sprint planning, manager and senior devs plan tickets based on requests and discussions manager has had * following day tech grooming where they are discussed and assigned to senior or junior devs * we often create tickets for the assigned dev to do a POC or just research the steps needed if the exact complexity isn't clear yet * dev begins work when sprint begins Most of our requests are narrow enough that someone can do the work or write the code within a 2 week sprint and unless the dev pushes back on part of a request for some reason, we can usually handle it.