Webinar Q & A: Six Steps for Successfully Scaling Agile
Thanks to everyone who attended the Six Steps for Successfully Scaling Agile webinars. The webinar recording is now available! Additionally, the full list of edited questions and answers from all three sessions is below.
Questions & Answers
Q: Are the swimlanes customizable? Yes they are. We call the vertical lanes columns, which is what I am guessing you mean by swimlanes (we use the word swimlanes for the horizontal groupings, e.g. by user story, or by user). See below, you can edit the Feature Kanban board which I have called Roadmap (if you are a TestTrack user just select Tools > Administration > Taskboard). You can choose as many columns as you want and name them what you want. One other important thing to remember about TestTrack’s boards is that they are controlled by the workflow that you define—you define which states appear under which column. You want to control the way you move across the board and almost certainly control who is allowed to approve features for investigation, or most especially who is allowed final approval. It is easy to allow anyone to move anything to anywhere on the board—but in my view, in a situation where you are approving high-level features, you need more control than that.
Q: How does rapid ideation work? This presentation wasn’t about rapid ideation, which I understand is about rapid prototyping. I would be very interested to get feedback about this, but I don't personally know enough about rapid ideation. Our design team and product manager work hard to make TestTrack methodology agnostic. So I suspect that TestTrack would work well for rapid ideation method but I just don’t know. Anyone out there with TestTrack and rapid ideation experience?
Q: How does the system handle distractions? There are things that could be distracting in TestTrack. For example, you can get a sound to play when something is assigned to you, we have recent activity streams, email notifications and that sort of thing. Like all distractions there can be a good reason for them. You want to be notified about important things that are urgent. So how do you handle this? Well there is no magic hard and fast rule but really it is about designing the process to get the balance right between information and notifications that are pushed to people (which could be a distraction) and information that they pull, such as by choosing to look at the boards or views. I’m part of professional services here at Seapine and my job is to help customers implement the best process using TestTrack. In terms of the balance between pushing and pulling information, what I generally say is that for most people who use TestTrack as part of their daily job, you should be careful about pushing information to them that they will be aware of anyway. For example, I always suggest that you don’t notify people every time they are assigned something, unless they are only occasionally involved in the process and need to be prompted. Too much info is just as bad as too little. Last tip: always turn off that sound on assignment unless you want to drive yourself mad :-)
Q: How well does TestTrack handle multiple products? There are two main approaches to handling multiple products. If the products and the people working on them are completely separate, then you can simply have two TestTrack projects which operate separately. However, a lot of our customers want to manage more than one product or team in the same project, because there is significant overlap between the teams, management, or they are linked in some way. For example, perhaps adding CRM capability would involve adding integrations to two of your products in which case you would want user stories for both of these products to be linked to the same feature. If you choose to have the two products managed in the same project, then you need to decide how to distinguish between items relating to the two projects. You can use a custom field “product” to do that, but the most common way is to set up parallel folder structures, one for each product. In my demo example, there was only one product, “Wysipump,” but see the pic below—another demo project I have has two products, “Wysipump” and “Bug Reporter.”
Q: Can you trigger a card/story moving with a source commit? Yes you can. You can perform a TestTrack event as part of your check-in process from your IDE, which moves the card along the board. You need to integrate TestTrack with your version control system. See below, where TestTrack is integrated with Surround SCM, Seapine’s software configuration management system. Firstly, you need to tell TestTrack which source changes are related to this TestTrack card/story record. You can do this from within TestTrack, from within the Surround GUI, by a command line prompt, or by using integration with your favourite IDE. Here I am using Visual Studio. Because you have linked your TestTrack record to your source files, when you check-in (commit) your source changes, you are prompted for the Fix event (which is the event designed by me when I configured the process to indicate that the change has been completed). This is part of the workflow, and will automatically move the record to the specified state, which will move it to the desired column in the Taskboard as per my set up.
Q: Can you use points rather than hours? Every record can be estimated in story points or hours, or anything else that can be expressed as a decimal or integer number. In my example, features and user stories were estimated in story points, whereas tasks were estimated in hours. A key thing that you need is the ability to provide estimates in at least two levels—a high-level estimate for your strategic planning when looking at Business Case and Roadmap planning, and then when you are in your sprints, you need estimates for the user stories and tasks to determine how much can be done in any one sprint and release.
Q: Are unfinished tasks/stories automatically carried to the next sprint? We don’t have the concept that you are just working on one sprint at a time. What if there are many teams, for example? A sprint folder is simply a container for everything that is planned to happen in that sprint. If items are not completed at the end of the sprint, they will not automatically move to the next one. You need to decide what to do with unfinished items. Often that will simply be to move them to the next sprint, but you have to do that manually.
Q: Is this process similar to Scrum? In the presentation, steps 4, 5, and 6 are Scrum; steps 1, 2, and 3 are about the higher-level business planning processes. Hopefully you saw the value in integrating these steps, which we believe is critical to scaling Agile.
Q: Is a user story a requirement type or document? A user story is a requirement type.
Q: In step 2 - how do we calculate final score? Create custom fields, and then a calculated field that can be any calculation you like. See here the formula for my Prioritisation score field.
Q: Can you touch on QA relative to what we've seen on using Kanban within TestTrack? I didn’t really talk much about QA, as I wanted to focus more on the management of your process. But test case management and defects are a full part of TestTrack, and you should carefully consider how to do this when building your end-to-end process. The way test case management works in TestTrack is that you create one or more test cases for each user story—see below showing how to generate test cases from a user story (you can also create separate unrelated test cases if you wish).
You then generate a test run record each time you do a test case within each sprint. Choose your test cases based on which user stories are in the sprint, and also by making a judgment as to what degree of regression testing you need for this sprint. You can then track each execution of the test to validate your user story and record any defects that you raise and fix within the sprint if you wish (you may run the tests more than once within a sprint if you raise and fix defects within the sprint). See below, where us-2551 is tested once and fails - TR-5776 - then DF-821 is raised, fixed, and closed during the sprint, finally a retest - TR-6160 - passes, so all is good.
You should also automate your testing when you can, so you can quickly perform regression tests. Because QA is part of TestTrack, I think it is quite easy to include a view on QA as a part of your normal end-to-end process. Here is an example of a report showing the end-to-end progress in terms of tests completed and defects found and closed.
Q: For testers, can we actually report and track the defects? Yes, you certainly can. See the earlier question about QA, which explained about defects and tests. Defect tracking is a full part of TestTrack. I just didn’t talk too much about it as I wanted to focus more on the end-to-end management aspect.
Q: Is there any strategy provided to connect user stories and tasks with other architecture /design elements like use cases? Very interesting question. I definitely agree that there are lots of other ways to design your system than simply user stories. In my demo, you may remember things like functional requirements and business requirements popping up. In my view, you should employ whatever method is best to design and document what your product should do. User stories are a good way of doing this, but you don’t need to limit yourself to that method of design. Here, for example, is a TestTrack document that has use cases, functional requirements and non-functional requirements. There are many things you may want to record about the design of your system that don’t necessarily fit well with the user story format. My advice would be don’t feel that you have to shoehorn everything into the “as a user I want to do this so that I can achieve that” format, which sometimes just doesn’t work; use cases, business rules, etcetera, all have an important place. That is not to say that I don’t think the user story format is not a great insight—it is, because it forces you to constantly question the value of what you are doing from the correct viewpoint.
The other key thing to consider when looking at this is that the user story performs two functions within your process. Firstly, it describes what the system should do, but equally importantly, it also functions as a unit of work to be tracked. This is what makes it so great. So, if you don’t want to use the user stories format to design your system, then don’t. The beauty of TestTrack is that each paragraph in your document is a record. So, as in the above example, you can choose to design your system using use cases or functional requirements, and then track your work at either the Use Case Overview or functional requirement level. Alternatively, use user stories as your unit of work, and simply link any use cases to this parent user story. The choice is yours. The trick is to make sure that you think clearly about it when you are writing design, when you are tracking a unit of work, and when you are doing both. Feel free to have a mixture of different elements in your backlog.
When my colleagues and I do an implementation, this is exactly the sort of question we discuss and help work through with our customers. The right answer depends on many factors relating to your situation, type of software, culture, and regulatory environment.
Q: Is it possible to show in the Kanban board more than one level between stories and tasks? Like Theme->Epic->User Story->Sub User Story->Task. Currently the elements are shown many times but only in a one-to-one connection. No. In the boards you can only see parents and their children. You can set up any number of levels of hierarchy within TestTrack either in a document paragraph structure (see examples in the answers to other questions) or as links. So the hierarchy that you describe can certainly be constructed and makes a lot of sense. You can look at the hierarchy either in a document or use a matrix report like this.
Q: Is it planned or possible to transform an element type from story to epic and vice versa? Currently epics are not really usable, because they are a complete different type. Yes, you can change any requirement type to any other. Epics and user stories are set up as requirement types and as you have seen, each can have different field values, different visible custom fields, different workflows, and etcetera.
Q: How many Agile models do we have? Seapine’s design team and product manager work very hard to ensure that TestTrack is model/methodology agnostic. We believe that this is the only way to build a practical tool that can work in today’s heterogeneous environment. In my view, this is one of the reasons it works so well integrating the higher-level planning into the lower-level agile teams. That’s a long winded way of saying that you, perhaps with our help, can set up TestTrack to support whatever Agile model best suits your situation. By the way, I don’t mean any bespoke changes to the TestTrack software or anything like that—I just mean the user configurations that you add. For instance, you might choose to have epics rather than features as your top-level item. In our view, this flexibility is critical because otherwise, you will never really be able to have the process working as you need.
Q: Can the features be automatically integrated in the roadmap? No—but if you wanted to do that, you could have the roadmap as the first step in the process when you create a feature. You could use an automation rule to prevent the creation of a feature unless it is in the roadmap document. It would still appear in the Kanban board (another rule would be needed to add features to the correct folder).
Q: Are the tasks stored in the same document as the user story? In the demo, they were not—but you could do this if you wished. They could be both in the document and in the Kanban board at the same time.
Q: What's the difference between a user story and a task? A user story is a description of what the system is to do. A task is something that someone needs to do to create this functionality. For example, a user story is “as a sales manager I want to be able to see all the accounts that my team are working on” a task would be “make a database design change to incorporate a field to track teams” and another one “code the report to filter by team.” Once you do both of these tasks, your user story would be done and the system would do what was described in the user story.
Q: Who is responsible for each step? If you are talking about the steps within the Kanban boards, e.g. the feature approval, then you can control who is allowed to do which step by adjusting the event permissions in the Security groups. If you mean more generally about Scrum roles, the information I presented today covered all the Scrum Agile process…this encompasses steps 4, 5, and 6, but also some roles not covered in Agile. These are the senior leadership roles, responsible for things like strategic direction, business case and approvals. Traditionally, this would be the provenance of the PMO office. So in terms of Agile roles, the product owner would be responsible for the creation of the feature user story breakdown (even if they did not write all of the user stories themselves) and would be responsible for ranking the user story backlog. Sprint team members would add tasks and participate in sprint planning with the product owner and Scrum master…all just the straightforward Scrum roles. So it’s up to you to decide who does what really, but the crucial bit about this approach is that it allows all the Agile roles to do exactly what they should, just integrated with all the higher-level business planning that will go on somewhere in your organisation.
Q: Whom can I contact if I have more questions? Ask me directly - firstname.lastname@example.org.
Q: Can we have the slide deck please? Yes it is here: http://www.slideshare.net/seapine/six-steps-for-successfully-scaling-agile
Q: What version of TestTrack were you using for the demo? I was using Seapine Software’s TestTrack 2015.1 for the examples and the demo.
Q: Which products/licenses are needed to cover the shown functionality besides TestTrack and requirements management? Everything we looked at was in one product, TestTrack. That is part of why it is so effective, I think. You need a TestTrack and TestTrack RM (requirements management) license to do everything that I showed you. You would additionally need a TestTrack TCM license to include test case management (note, the TestTrack license includes defect tracking).
Q: Is there a Mac /web client? Yes! Everything I did in the demo works exactly the same in our web, Mac, Windows, and Linux clients.