One thing we learned early about creating custom software: open communication lines are absolutely essential. We need to make sure we are constantly updating our clients on how things are going on our side. And we need to get our clients to answer questions quickly to keep things moving from their side.
To that end, each EduSource custom software project has a Client Communication Board. Here’s what they are and how they work:
Here’s a screen shot of the top of one of our Client Communication Boards. (The client name is blacked out to protect client privacy.) After the Primary Problem Statement and the Objectives, the next things you see when you open your board are our client metrics. These are the three graphs at the top of the page.
What does this show? The first graph shows how well we’re doing with planning out work ahead of time. Before you and your Client Relationship Manager (CRM) can pull User Stories into your EduPoint Queue, we have work to do to make sure these stories are ready for development. This graph is all about making sure we have plenty of work ready for our developers to work on.
What does it mean? See the black and gray lines on the graph? The blue lines should all fall between the black/gray lines. If they do, this metric is green, and plenty of work is available for you to put into your EduPoint queue. The two lighter blue lines are steps that our Business Analyst (BA) and developers need to take to make sure they understand exactly what the User Stories need to do and that they have appropriate acceptance criteria (criteria that tell us whether or not we completed the User Story as expected). The dark blue line shows us how many User Stories are ready to be pulled in. If that dark blue line is within the black/gray lines, we are doing just fine, and have plenty for the developers to work on.
What does it mean if this metric goes red? It can mean one of three things. First, it can mean that we are waiting for information from you. If we need you to answer questions before we can complete refining or reviewing User Stories, and you don’t have time to answer, your team will be held up. This can turn the metric red. (See Action Items section below.) Second, it might mean that our Business Analyst (BA) is falling behind. If this is the case, feel free to bring it up to your CRM. We’ll be working to correct it. Finally, it could mean that our BA has been overzealous and has TOO MUCH that is ready for development. Why is that a bad thing? Well, if we get too far ahead of ourselves, work can get “stale.” We don’t want to work too far in advance, because we keep learning and designing things as we work, and we might end up having to rework those stories, based on the things we’ve learned and designed.
Why do I care if this metric is red? Well, if your dark blue line dips too far below the black line, it’s possible that developers will be sitting around with no work to do. If this happens because we can’t get ahold of you to answer questions, we’ll keep charging you for your EduPoint rate, even though we can’t keep moving ahead. Obviously you don’t want that.
What does this show? This graph shows how efficiently our team is working. The black line shows your EduPoint rate. The blue line shows the average of how many EduPoints your dev team is completing each week.
What does it mean? Each week in your replenishment meeting, you’ll sit down (or have a phone call) with your CRM to choose User Stories to pull into your EduPoint Queue. Our goal is to get all of these EduPoints through our process in three weeks or less. Of course, during these three weeks, we’re still adding more points each week. This client gets to pull in 10 EduPoints each week. This graph shows how many EduPoints we are completing each week, compared with the 10 we are planning to complete. Sometimes the number completed will be more than the black line and sometimes it will be less. But we want the blue line to average right around (or above) the black line.
What if this metric goes red? Well, that indicates that something is making our team work inefficiently. It could be that our team just isn’t getting work done like they should. Or it could be that they have run into unexpected complexity. This happens all the time in development, but usually we are able to make it up. At EduSource, our commitment to you is that if we can’t make it up, we’ll have you stop paying for a week while we get caught up. This is our motivation to work efficiently.
Why do I care if this metric goes red? Obviously you want us to work as efficiently as possible, since you are paying by the week. If we get fewer EduPoints completed per week, the project will take longer to complete, thus costing you more. If we get more completed than expected, you should be throwing your dev team a party. That’s saving you money!
What does this show? This graph is tracking how long the project will take to get completed. The lime-colored line is showing our planned EduPoints and how they work their way down by the 10-EduPoint rate, until they hit 0 and the project is complete. The blue line shows the actual EduPoints we are completing. In this case, the dev team is ahead of schedule. The black line shows the scope floor as we originally scoped out the project (which speaks to the original date we expected the project to complete). One of the benefits of Agile Contracting is that clients can add to or change scope dynamically. However, we do want to help you keep in mind that adding scope will change your timeline. The dark green line shows the added scope and how it affects the timeline.
What does it mean? In this specific case, it means that the dev team is working a bit more efficiently than expected. And that the client has added scope, changing the expected end date from 6/15 to 6/30ish (which means an additional investment of $6,000 on this mode).
What if this metric goes red? As you can see, this metric can be red, green, or yellow, which means “changed.” In this case, the scope has changed considerably, so the deadline has changed, as well. If the number of EduPoints left is significantly more than the original plan, the graph will go red, showing that your dev team isn’t working efficiently enough to meet the expected deadline. As with the previous graph, if we get too far behind, we’ll let you take a week off payment while we catch up.
Why do I care if this metric goes red? Obviously, you want to minimize your investment. Extending timelines will mean more investment. If you think of additional features you’d like to add while the project is in process, you may be fine with the additional investment. Also, you may have a very fixed deadline. If that’s the case, you’ll want to keep a close eye on this graph to make sure your team will hit it.
The Decision Log is exactly what is sounds like. Any time a decision is made about your project (adding new scope, deleting scope, changing EduPoint modes, etc), it will be logged here. At any time, you can go back and look at decisions. Either you or your CRM may add something to the decision log by clicking on “Decision Log” on the right-hand-side of the page.
When we need information or clarification from you, it will show up here. We will add a due date with the date that we ABSOLUTELY must have this info without slowing up your dev team. Please pay close attention to this area.
This area is for anything you need to upload for us to complete your project. This could include screenshots, screen mockups that your team has prepared, logos, or notes. You can upload anything we need here, and the date it is uploaded will be recorded.
This is your area! This shows User Stories that are ready for UAT. Each week in your replenishment meeting, your CRM will demo these new bits of functionality to you. From there, you will have one week to play with the new functionality and see what needs fixed. Any bugs you find in these stories will be sent back to the developer for fixing. Anything you decide to change on these stories (as long as they meet the original acceptance criteria), will be added as new User Stories and sized appropriately. To test these items, you’ll follow the link at the top right of the list.
This shows you the items that your dev team is currently working on. They may not be in the same order of your queue, since there are times that certain User Story sizes make sense to grab (an apprentice will usually stay away from larges, for example, because they take much longer to complete).
This is your EduPoint Queue. During your weekly replenishment meeting, you’ll work with your CRM to decide what comes next in the queue. Occasionally, your CRM will explain that certain User Stories need to come before others to make dev work appropriately. But other times, you’ll be able to choose which functionality you want to see developed next. The “Total EduPoints” column shows you which size the story is (extra small: 1; small: 3; medium: 5; large: 7).
Underneath that list, there are three small lists that you can minimize or maximize. These show the specific User Stories that are in the Reviewing category (being looked at by the BA); the Refining category (being checked over by a developer); and the Backlog category (ready to go, but not in EduPoint Queue yet.
Finally, at the bottom of your Client Communication Board, you’ll find some legal-type things.
This is where you’ll find all of your invoices. Of course, we’ll send them by email too.
We’ll keep a copy of your signed Master Service Agreement (MSA) and your signed Statement of Objectives here. That way, if you ever have questions about how we do things at EduSource, you can peruse these documents.