Changes
/* An Epic for every topic */
The project should be segmented into Epics first. An Epic is a large work package corresponding to a topic or an abstract use-case.
For example, Operator Rounds (using the mobile application to do maintenance in a plant) are a classical use-case that can be managed with {{UBIK}}.
However, for the sake of project management, it makes sense to make sure Epics have a limited temporal scope as well. This means that they should be doable within a short period in time. The benefit of this is that you can collect moments of success more frequently, and you can sell those to the customer, too.
For example, you could divide the Operator Rounds Epic into two stages, Operator Rounds I and Operator Rounds II.
Further, you can try to create elementary work packages that do not have any dependency in the middle, but only as a whole. This way you can avoid an Epic being blocked in the middle of its implementation, making it easier to deal with if it is blocked. Also, this proceeding allows you to model dependencies more clearly and plan accordingly.
[[Category:Best Practices (internal)|Organize UBIK Development]]
[[Category:How-To|Organize UBIK Development]]
[[Category:Resources (internal)|Organize UBIK Development]]
==== A Feature for every requirement ====
