A quick recap from part 1 (you can read the entire post here). This post aims at clarifying the role and responsibilities of a project owner with regards to projects requirements, which are not to be confused with user stories. The latter is in fact a representation of those requirements that intermediate the communication between business stakeholders and the development team.
With these premises, let’s go back to our initial goal: given a set of requirements capture in one or more meetings and interviews (well detailed in part 1), let’s make sure that your development team deliver exactly what your stakeholders ask for.
We have designed an ideal workflow to manage the complete lifecycle of your requirements.
1. Capture the real pain (aka do not believe your users’ first version)
The goal is to understand the real pain experienced by users which your project is aiming to solve and this can be achieved by, well, not believing what they say they want in first place. Business users will not be nearly pragmatic enough to define a requirement with all details, in most cases they will report a set of daily manual activities which lead to some general rule that has a plethora of exceptions. The most appreciated soft-skill of a good project owner and/or analyst is to understand where the real pain of your business stakeholders sit and to derive from that the real general requirement.
An example? The business user asks for a new form to manage all the expense of the company. The truth is that they are managing them already (most likely with a lot of manual labor) and they want to automate the approval process. Actually, they’d love a system that, once approved, let them forget of all that paperwork forever! The process and therefore the requirement are different from what the user initially asks for, so the result that is being asked of the team will also be different.
2. Explode users' requirements in stories
Your users' requirements are then broken into many functional blocks, often interdependent, through an amplification activity. The team breaks each requirement into many discrete and manageable user stories. At this stage, effort can probably not be evaluated in detailed metrics such as man-hours, yet a pretty well-spread alternative is to assign stories an index of complexity such as story points, pomodoros or some other arbitrary effort indicators. Herogami supports story points as well as pomodoros, but also color-coding and other user-definable attributes.
3. Translate stories into tasks for techies
This is the easy part. It's about getting your development team in the cafeteria or some meeting room and discussing the details of the implementation. Try not to dive too much into details, leave something for other rounds as well: Agile tactics include shared responsibility and each developer is responsible for its area, therefore you as a project manager can avoid the risk of falling into micro-management traps.
The goal of this phase is to derive, for each story, the tasks that developers need to complete. Having a clear set of tasks for your stories helps your developers understanding problems before they occur. It also helps to properly estimate the duration of activities, so as to avoid any form of guessing. Every story in Herogami has an internal kanban for tasks and they are super quick to enter.
4. Define effort estimates and contingencies from information or technical debt
With the tasks defined it is easy to indicate the effort required by the various stories. The sum of the effect, net of parallel activities, will provide a release date for the first test or the sprint review. Sounds simple, right?
The point is, most likely, that your requirement is not entirely complete, so you have to handle an information debt that will surely result in additional unplanned effort. Here are no rules, the sensitivity of each professional varies but the rule is to add a good 20-30% contingent effort to cover the risk. In Herogami you can enter effort in man-hours or pomodoros, and due dates for stories and issues are clearly displayed on the shared project calendar.
5. Run stories in one or more sprints keeping an eye on WIP limits
Stories can be put into work by relocating them from the backlog to the current sprint. Developers will move the cards while performing tasks, and Herogami will provide a proper project and sprint status through dashboards and burndown charts. This is a fantastic tool to understand the trend of the sprint and it is very complicated to handle it manually. Fortunately, Herogami updates the current sprint burndown chart whenever an activity is performed on a story or issue, in a completely automatic and transparent way. Make sure you configure Herogami’s WIP limit at every step of your workflow to avoid overloading your developers.
We’ll see two more points in the upcoming part three of this post and drive some conclusions on effective strategies to manage your business requirements and user stories with Herogami. Stay tuned!