Let's Talk Software

Even if you're not looking for custom software development, we're happy to chat about agile processes, tech stacks, architecture, or help with your ideas. Enter your contact information below and a member of our team will contact you.

    Clients who trust us to deliver on their custom software needs.
    Tonal Logo
    Aquabyte Logo
    More Cashback Rewards Logo
    MasterControl Logo
    Little Passports Logo
    Mido Lotto Logo
    Software Development Capabilities

    AI, ML & Data Science Services… a Paradigm Shift in Software

    Artificial intelligence affords opportunities to automate tasks human being might complete faster and more accurately than a human beings are capable. And CodeStringers has the expertise to bring your AI product to life with our data science services.

    Our AI, ML & Data Science Services.

    Data science services can help you get deeper insights from your data. It can also enable your product to predict user actions or outcomes. We can help you advise users of decisions they should make or actions they should take.

    Custom Artificial Intelligence

    Have a source of big data with untapped value? CodeStringers data science services can help ideate use cases to extract greater value and then develop custom AI solutions to deliver that value.

    Machine Learning

    Machine learning allows computer systems to independently learn and improve from experience. The more data the system analyzes, the more accurate the results and predictions.

    More

    Our ML developers use Python and ML frameworks such as TensorFlow, Torch and Theano to develop descriptive, predictive and prescriptive capabilities.

    Deep Learning

    The term “Deep learning” refers to a method of teaching computers to analyze data as a human being would if capable of processing “big data”. It is used to recognize patterns, whether analyzing text, images, video, or audio.

    More

    A self driving car identifying traffic signs and signals. A meeting transcription solution identify action items and their owners. These are examples of how deep learning works within broader AI and ML solutions.

    Regardless of your industry or market, CodeStringers data science services can help develop deep learning solutions for natural language processing, image or video object extraction and classification, or any other need your organization has.

    Data Aggregation / Augmentation

    Many AI and ML solutions can be improved by sourcing additional data. A self-driving car might adjust braking in rain or snow, for example. An promotion/email marketing system might delay email messages to consumers in areas with a surge in Covid cases.

    More

    CodeStringers has experience in building data collection and aggregation ranging from Application Programming Interfaces (API) to open source or commercial data to web crawlers for Internet and Dark Web sites that download webpage content and store it in an unstructured database (Solr, Elastic).

    We can help your organization identify data that may improve your AI/ML solution and build the system to capture, store and incorporate that data.

    Data Modeling in Data Science Services

    Data modeling is the process of creating a visualization of data objects and their relationships and then building a data structure from that visualization. As an example, a data model for facial recognition would have entities for facial features (noses, ears, eyes, mouths) and their relationship on a person’s face relative to one another (eyes side-by-side above the nose, etc.)

    More

    Data modeling is a critical initial step in building any AI/ML solution.

    CodeStringers utilizes entity-relationship diagrams, and data normalization techniques to conceptualize data models and then build those data models using relational, document, graph and other database technologies to actualize the model.

    We are technology agnostic, working with PostgreSQL, SQL Server, MongoDB, Solr, Elastic, Cassandra, Neo4j and other SQL and NoSQL database technologies – whatever best suits the functional and non-functional requirements..

    Key agile release planning information.

    Below is a taste of CodeStringers’ expertise in agile planning and development. to get the full meal, visit our agile resource center.

    What’s a User Story?

    A user story is the definition of a software feature to be built. User stories have a specific format that includes four fields (three illustrated in the picture above):

    • Who is the user persona for the feature?
    • What does that user persona want the software to do?
    • What goal does the user persona have that the feature will achieve?
    • The “Definition of Done” in the form of listed acceptance criteria.

    The term “user persona” simply means a description of the prototypical user of the feature. Software products may have a single or multiple user personas.

    The format of the story is:
    • As a <user persona>…
    • I want to <what the user persona wants the software to do>…
    • So that <the objedctive the user persona wants to achieve>.

    Acceptance criteria are typicallly use cases. One use case is the “happy path”… what happens if the feature works as expected. The others are “negative use cases”… what happens when the software doesn’t do what the user wants.  For example, take a “login” feature:

    • The happy path is that the user inputs a username/email address and a passsword and gains access to gated functionality.
    • Negative use cases are what happens when the username/email is bad; the password is bad; both are bad… in the case of a mobile app, what happens when there’s no connectivity.
    Well written user stories meet six criteria articulated as the acronym “INVEST”:
    • INDEPENDENT: Each story must not have functionality that overlaps others. Login is independent of password reset, for example.
    • NEGOTIABLE: Perhaps the most forced word in this acronym, “negotiable” simply means that the team can understand the story and acceptance criteria.
    • VALUABLE: Each story creates value for the customer.
    • ESTIMATABLE: The team can size the effort to deliver the story.
    • SMALL: Stories are small enough to be completed in one sprint… perhaps even smaller. Some organizations dictate that stories must take less than a few days. Stories that are too large are often too complex and need to be “broken down”. 
    • TESTIBLE: The acceptance criteria for the story can easily be translated into test cases, eaching having an expected result. When tested, if the expected result does not occur, a defect exists. The story is not “done” until all defects are cleared.

    Estimating User Stories

    Estimation of user stories is done by assigning a numeric value to each story called “story points”. Story points are an abstract concept but an important one in terms of the psychology of a development team.

    Prior to Agile / Scrum, development team members were all asked to provide estimates in time for everything they did. This was often referred to as “man-hours”. The problem is that each feature built could involve multiple team members, each one having to provide an estimate. Consider building a web application. You have a UX/I designer, a frontend web developer, a backend API/service developer, a database architect, a manual quality assurance tester, and a test automation engineer. Each one must complete work for a given feature to meet the acceptance criteria.

    How much time would it take to get estimates from each team member so that you know the total effort? How do you know if those estimates are accurate? What culture does it create when team members give estimates that are wrong (low) and are later criticized for the inaccuracy?

    Enter the Story Point

    Story points are a numeric value that the team collectively assigns to each story in the backlog and does so using “relative” estimation. Rather than each individual answering the question, “how many hours will this take?”, the team together is asked, “what stories that we built historically is this larger than and which ones is it smaller than?’

    Most development organizations use Fibonnacci numbers as their story point values: 1, 2, 3, 5, 8, 13, 21, 34…

    So, how does it work?

    The team looks at a given story and realizes it is larger in effort than one story built recently and smaller than another. The first of those took 13 points. The latter took 5 points. So, the estiamte for this story is 8 points. And move onto the next story.

    Why is this method valuable?

    #1 – Speed

    Ask people for time estimates and they’ll spend time trying to make sure they’re not low in their estimate.

    #2 – Less Sandbagging

    Ask people for time estimates and they’ll likely estimate high on purpose because it’s better to “under-promise and over-deliver”. Problem is that this may get to the point that estimates are so high they are of no value. Worse, once people are told that an estimate is accepted, they may find ways to actually use all of the time they’ve been given to deliver (i.e. they don’t work hard).

    #3 – Culture

    Asking individuals for estimates creates a individualism culture, which is the fastest path to a low productivity product organization possible. As the saying goes, “There is no ‘I’ in TEAM.” When you ask teams to estimate together, no one person feels politically exposed. If the team is wrong, we learn from it. However, if a person is wrong, blame is assigned.

    Velocity Explained

    The term “velocity” is a unit of measurement in Scrum to illustrate the average number of story points completed in sprints. It is hugely important for a few reasons:

    #1 – Planning Future Sprints

    It’s important to plan sprints such that the volume of points planned is slightly higher than velocity. Why? Because you always want your team to have goals that push them to increase velocity but not so much greater than velocity that the team feels defeated.

    #2 – Release Estimation

    Scrum as a methodology does not discuss release planning, but the reality is that few if any product versions only require one sprint to complete. Releases typically include multiple sprints.

    Businesses need predictability. How do you plan sales and marketing activities if you have no idea when a product version will be released? How do you forecast revenue and profitability? You don’t.

    As such, velocity allows teams to estimate product version release dates early in the release development. Here’s how it works.

    The team completes a few sprints to establish a velocity of 50 points (per one-week sprint). The team then estimates everything remaining in the product backlog (for that product version) to sum to 2,000 story points. Divide the sum of the backlog estimates by the velocity: 2,000 / 50 = 40 sprints/weeks.

    Now decisions can be made. If the organization needs the release in 30 weeks, it may be possible to add resources to increase velocity. Moreover, the organization can now track progress sprint-by-sprint to ensure that the team continues to track to the release date and adjust as needed. No suprises at the end. of a cycle.

    Related Posts

    Getting started with software development services is simple & painless.

    Within a month, you can see your idea start to come to life.

    Get started utilizing our software development services
    STEP 1

    Exploration

    We complete a series of discovery workshop sessions that take anywhere from a one day to a couple of weeks depending upon the complexity of your idea. The workshops help our team understand your vision and gather sufficient information to create an agile software release plan.

    STEP 2

    Release Planning

    Our team creates an agile software release plan including customer/user personas and needs, feature requirements, user interface wireframes, technical architecture and tech stack, and estimates of effort duration and budget. In order to tailer our software development services to your needs, this plan is an essential step. This typically takes one to two weeks to complete.

    STEP 3

    Engagement Model & Team Structure

    Within days, we agree upon the best customer engagement model for your needs, the skillsets needed, and the structure of the team.

    STEP 4

    Build Software & Track Results

    We initiate agile / scrum development utilizing CodeStringers’ expertise and experience with the methodology. We conduct routine status reviews and demos, give your team direct access to a test environment for your software, and provide progress reports on features completed, QA testing results, and a burn down against the original release plan. If our estimates were low, we know early on. CodeStringers adds resources to hit the deadline at no cost to you.

    Scroll to Top