Agile Project Management with Riter
Every day we are faced with the results of rapid technological evolution and continuous innovations, and software development and project management are not an exception. Customer and market requirements are constantly changing so IT companies need to keep an eye out and respond quickly to any of them to stay successful. Under such circumstances, no wonder that Agile principles attract more attention and are firmly established in the software industry (and not only there). There is an increasing number of teams working on Scrum, Kanban or some hybrid methodology and, as a result, they begin looking for new project management tools suitable for their workflow. How much does Riter, designed as an Agile project management software, meet their expectations? In this article we will show how main Agile artifacts can be mapped on the existing Riter functionality.
User story is one of the key concept in Agile methodologies which includes a short and simple descriptions of a new desired feature told from the perspective of the person who needs this capability (as a rule, this is a user or a customer). In Riter, we also use project stories to describe a necessary functionality, however, here you can also use stories to specify any other task within a project (a new feature, a bug, a meeting with team members or something else). Anybody assigned to the project can create new tasks. Stories in Riter don't have some specific format like user stories do. The only thing that should be specified is a title. You can also add a detailed description for each story, conditions of satisfaction, related information, links to dependent tasks, and so on.
Besides user stories, Agile methodologies usually include such concepts as tasks and epics. Task is some work that needs to be done within a user story. Each user story can include several independent tasks. Riter supports this capability: you can divide each story into several subtasks and list them in the story description as todos (just use markdown/toolbar checkboxes). This will allow your colleagues to better understand what exactly you are going to do, and at what stage you are now.
Epic is a wider scope of work which can cover several user stories. Riter doesn't have such a notion itself, however, it provides several levels of scalability and the next one after a task (a story) is a project. Each Riter tariff plan allows you to create any number of projects, so do not hesitate to create a new one for some related tasks when necessary. You can also work with groups of projects simultaneously.
A backlog is an ordered list of everything (features, functions, requirements, improvements and fixes) that might be needed in the product. It is constantly updated during the development process with new changes appeared. A backlog is a necessary attribute of Scrum methodology and it's implemented in Riter as a list of all stories placed on the main project page. These stories are grouped by sprints which they are planned for. If you don't specify a particular sprint for a new story, it will be placed into the section of unscheduled stories. Such a solution has some differences from a traditional Scrum backlog. First of all, Riter's list of stories will include approved stories of the current sprint (and all future sprints if they were done in advance). When the sprint finishes, all its approved stories get to the archive automatically. If there were unready stories, they will be dropped into the overdue section. If you need to hide approved or some other stories from the list, you can do this with available filtering options.
The second difference is that a list of stories in Riter is not ordered automatically by a priority or some other criteria. However, you can easily arrange tasks in any order you need just dragging and dropping them in the right place not only within their sprint section, but between sections as well. The fact is that the use of priorities, for example, "minor", "important" or "critical", although universally used, does not really make much sense. If something is so critical indeed, the last thing you should do is creating a task and marking it with such a priority - as a rule, the preparation of reports and other bureaucracy in such cases is carried out after the problem has been solved. Moreover, Riter supports topics, so you can emphasize the importance of a specific task with an appropriate tag, for example "urgent" or any else. In this way, you can use topics instead of priorities and just sort stories manually in the order of their urgency for you backlog. However, we are going to add priorities in Riter future releases to support common practices for your convenience.
As you could already see, Riter supports the concept of a sprint as it exists in common Agile methodologies. A sprint represents a finite time period in which the work should be completed. It may be a week, a few weeks, or perhaps a month or more, however, one or two weeks are the most often choice. In Riter you can specify a length of a sprint for each project on the stage of its creation. You can also choose a weekday when a sprint should start. All tasks in a project are grouped by sprints (if only they are not placed in the unscheduled or overdue section). Statistics is also shown for specific sprints.
Such artifacts as Kanban or just task boards are widespread in Agile. They represent all tasks grouped by their states, for example, "Todo", "Doing", "Done". In Riter we also distinguish stories by states: "Draft", "Estimated", "In process", "Completed" and "Approved". Each state is distinguished by its own color. States can only be changed sequentially. At the moment we are working on the possibility to add new states for projects. Then users will be able to add their own development stages, for example, "Testing", "Documenting" and so on for more flexibility. You can order stories by their states manually within their sprint sections if you need, however, it's not necessary - thanks to their colors, you can easily distinguish stories with different states. You can also use filtering by states to show/hide only some of them.
The next often attribute of Agile practices is a timebox. This is a previously agreed period of time during which a person or a team works on some particular task or a set of tasks. The Agile process suggests creation of time boundaries for all key events, including development. In Riter, we have realized this capability with sprint intervals for scheduling work on some period and time estimation for each specific task. So you can plan further work in a team and keep your colleagues informed about the basic terms of work. However, we understand that a real estimate of a task does not always coincide with our expectations, so that Riter also allows you to flexibly change the timeframe, specify how long it really took to finish a task and redistribute tasks between sprints.
A frequent approach to estimating stories in Agile is using story points instead of some time values. Here Riter moves away from the standard solution with story points to solve a number of related problems about which we told before. In addition, the use of time estimates allows us to realize the time division into clean and dirty hours, which in the nearest future will be used by Riter AI to calculate the team's productivity and accuracy to predict more exact deadlines. Nevertheless, for more conservative users we are going to support story points estimation later.
Poker planning is a consensus-based estimating technique for Agile teams in which several team members discuss each new user story or a feature that should be implemented and provide some estimates for it. If someone's opinion strongly disagrees with the majority, they ask him to justify such a decision. The process is repeated until consensus is achieved or until the estimators decide that a particular story can't be estimated until additional information is acquired. We are going to implement the main idea of poker planning in Riter in the following way. Each story will need to be estimated by several developers until Riter AI decides that it has got enough information to calculate the accurate time value, taking into account the previous accuracy of each developer.
Burndown charts and burnup charts track the amount of output (in terms of hours, story points, or backlog items) a team has completed across an iteration or a project. They help a team to know if they are on track in real time, and mitigate risks as they arise. Riter doesn't provide any charts at the moment, but they will definitely appear in future releases. Moreover, at the moment we use another way to inform developers about possible terms determination. On the right of each sprint time boundaries you can see nicknames of all team members of the current project with some time estimates. They show how many hours are planned for each developer in a specific sprint (taking into account the time spent on tasks from other sprints in the current sprint period). Riter knows how many hours in average a particular developer usually works per sprint, so if this estimated time is higher, it will be highlighted with a red color, to draw the attention of the team to existing risks and the possible need to redistribute tasks.
At the end of each iteration, a team adds up effort estimates associated with user stories that were completed during that iteration. This total is called velocity. Riter also shows this value, just not in story points but in hours spent on all tasks during a sprint by a particular user and all the team. These estimates can be found in Riter statistics that also includes a lot of other useful information.
Sign up for tasks
One of frequent Agile attributes is "Sign Up for Tasks" approach: members of an Agile development team normally choose which tasks to work on, rather than being assigned to work by a manager. Riter allows you to use this practice in your company as well: all developers involved in a particular project can assign themselves to tasks on their own without any restrictions.
Customer-first or requirements-first approach is a key concept in the Agile principles. Each Agile team should be open to changes on any stage of the development process. Continuous interaction with all involved parties, frequent iterative updates, responsive to changing of requirements - all these conditions must be provided be Agile oriented tools. Riter gives you exactly such flexible working conditions. Terms of tasks can be changed easily - just drag-and-drop a story to another sprint when necessary. Switch between story states to show its current stage. Advanced admin panel allows all interested parties track the workflow and stay aware of the progress. Business people and developers can work together daily throughout the project. Agile is a visual process: everybody should have access to other team's current activity, discussions, estimates, and Riter provides this for the whole team.
And finally, let's remember the rule of "Three C's": "Card, Conversation, Confirmation" - this is a formula that captures the components of a user story. Riter corresponds to this scheme. When a story is created, all team members can discuss it before (and during) its implementation. Comments are available to everybody within the project and their number is shown on the main page with a list of stories. Riter supports markdown for writing comments. What about confirmation, you should use story states for this to indicate the current state of a task, for example, "Draft", "Estimated", "In process", "Completed" or "Approved".
Riter development team