Please login or join to subscribe to this thread
I have no idea why you think it would be different. Work is work, you have to divide your work to elements and work packages. Maybe you do not have all of the details at first but you do your WBS to level 2 or 3 and then, if you need to, you expand it when you are defining the increments; or products
I wouldn't use a WBS on a project whose scope is 100% being delivered using an adaptive approach, but would use story mapping which will give you something which is similar to a WBS without going down to the lowest level of detail for the full scope or capturing unnecessary information.
Breaking down the project vision into themes or capabilities, then down into epics and finally into stories is just a different type of functional decomposition...
So we still do break down but now you call them using different names? It sounds like a typical Agile for me - use something that works, re-label it and promote it as Agile.
Maybe I should stay away from Software :)
If you look the most used agile based method en Europe (mainly UK) which is DSDM you will find the WBS inside it. So, my first recommendation, take a look to that method. But generally speaking (and I am using it) you can have something similar to WBS and Gantt charts just in case you need it. The hugh difference is in Agile based environments you are managing features instead of work. Then what you will have is a "Feature Breakdown Structure" and if you like to show an "type Gantt schedule" each line will be a user storie (just in case you use it) or a feature with time but not resources associated to it where "resume task" is the iteration that contains all the lines.
I'd encourage you to read Jeff Patton's book, User Story Mapping. A Story Map combines benefits of a WBS with a release plan...
In general, there will be some sort of decomposition activity to aid in completing a particular story. What that may look like will differ based on the organization, model, or team. Sometimes a set of tasks to fulfill a story will be thought through and created, say in JIRA, during a planning event or in preparation for one.
I think sure always must be construct WBS, without import if project agil or not.
I haven't come across a WBS in any of the agile projects i have been on
I go with Andrew Craig. In fact I used the same approach in my projects.
Good discussion. My 2 cents would be that WBS is still a very useful tool even in the Agile paradigm. While an agile approach takes care of core software development, the WBS at a slightly higher level tracks the entire project from initiation through the SDLC phases, productionization, trial runs, user training, migrations and closure - to name a few.
Please login or join to reply