process of dividing software development work into distinct phases to improve design, product management, and project management. The methodology may include the pre-definition of specific deliverables and artifacts that are created and completed by a project team to develop or maintain an application. Agile software development comprises various approaches to software development under which requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their customers/end users. It advocates adaptive planning, evolutionary development, early delivery, and continual improvement, and it encourages rapid and flexible response to change.
improve work across human systems. This approach aims to manage work by balancing demands with available capacity, and by improving the handling of system-level bottlenecks. Work items are visualized to give participants a view of progress and process, from start to finish—usually via a Kanban board. Work is pulled as capacity permits, rather than work being pushed into the process when requested. Teams at Marqeta use Scrum, Kanban and Scrumban. For Issuing Kanban boards, we are not using WIP Limits yet. The nature of the projects and team composition in Issuing squad made us prefer Kanban over Scrum.
is a collection of features or. user stories. User Story: User stories are a type of boundary object. They facilitate sensemaking and communication; that is, they help software teams organize their understanding of the system and its context. Task: Represents development tasks to accomplish a user story. We don’t use Bug, Improvement, New Feature, Requirements ticket types in JIRA much.
》 Born out of Epic Cases fast-follows 》 Product Manager (PM) created at 17th June 2019 》 By default the ticket went to Backlog of Case Management Kanban board 》 During weekly standup, the decision was made for engineer to pick it up 》 PM moved it from Backlog to TO DO at 24th July 》 Engineer moved it into IN PROGRESS and asked some clarification questions to PM and stakeholders 》 Engineer gave a user story point of 3 》 Engineer created a pull request at 27th July for review
》 Engineer moved the ticket to READY FOR QE 》 Engineer assigned the ticket to Test Engineer 》 Test Engineer updated user story point from 3 to 5 》 Test Engineer moved the ticket to QA IN PROGRESS 》 Test Engineer finished testing in 14th October and moved it to READY TO MERGE 》 It was deployed in production as part of MNTY rel-3.42.1 at 21st October 》 Ticket was closed by Test Engineer while also was assigned back to Engineer
by Agile teams for story point estimates – 1, 2, 3, 5, 8, 13, 21, and so on. Teams use this sequence, rather than a linear 1 – 10 as it forces them to provide a relative estimate. Easier to ask is that a 5 or an 8? than is that a 6 or a 7? Story points give us an idea how much effort will be needed and whether there is scope for breaking it down to smaller chunks of work. For more details, please check https://sites.google.com/marqeta.com/issuing/methodology
as our SDLC day in, day out 》 Dave White 》 Judy Tsui - Check her 25th April 2019 tech talk on Agile & JIRA Practices 》 Nick Petru - The owner of PS-5020 ticket